cómo proteger tu equipo de ataques

Muy buenas con todos, antes de entrar al hardening de tu equipo, quiero contarles que el installador que estoy desarrollando para Gentoo ya está en su fase pre-alpha :D esto quiere decir que el prototipo es lo suficientemente robusto como para poder ser probado por otros usuarios, pero al mismo tiempo todavía falta mucho por recorrer, y el feedback de estas etapas (pre-alpha,alpha,beta) ayudará a definir rasgos importantes sobre el proceso :) Para los interesados…

https://github.com/ChrisADR/installer

PS. todavía tengo la versión exclusivamente en inglés, pero espero que para el beta ya tenga su traducción a español también (estoy aprendiendo esto de las traducciones en tiempo de ejecución en python, así que todavía hay mucho por descubrir)

Hardening

Cuando hablamos de hardening, nos referimos a una gran variedad de acciones o procedimientos que dificultan el acceso a un sistema informático, o red de sistemas. Precisamente por eso es que es un tema vasto y lleno de matices y detalles. En este artículo voy a listar algunas de las cosas más importantes o recomendables para tener en cuenta al momento de proteger un sistema, intentaré ir de lo más crítico a lo menos crítico, pero sin ahondar mucho en el tema puesto que cada uno de estos puntos sería motivo de un artículo propio.

Acceso físico

Este es sin dudas el primer y más importante problema de los equipos, puesto que si el atacante cuenta con fácil acceso físico al equipo, ya puede contarse como un equipo perdido. Esto es verdad tanto en grandes centros de data como en laptops dentro de una empresa. Una de las principales medidas de protección para este problema son las claves a nivel de BIOS, para todos aquellos a los que suene nuevo esto, es posible poner una clave al acceso físico de la BIOS, de esta manera si alguien quiere modificar los parámetros de inicio de sesión y arrancar el equipo desde un sistema live, no será trabajo sencillo.

Ahora bien, esto es algo básico y ciertamente funciona si es realmente requerido, yo he estado en varias empresas en las que no importa esto, porque creen que el “guardia” de seguridad de la puerta es más que suficiente para poder evitar el acceso físico. Pero vamos a un punto un poco más avanzado.

LUKS

Supongamos por un segundo que un “atacante” ya ha conseguido acceso físico al equipo, el siguiente paso es cifrar cada disco duro y partición existente. LUKS (Linux Unified Key Setup) es una especificación de cifrado, entre otras cosas LUKS permite cifrar con clave una partición, de esta manera, al iniciar el sistema si no se conoce la clave, la partición no puede ser montada ni leída.

Paranoia

Ciertamente existe gente que necesita un nivel “máximo” de seguridad, y esto lleva a resguardar hasta el aspecto más mínimo del sistema, pues bien, este aspecto llega a su cúspide en el kernel. El kernel de linux es la manera en la que tu software va a interactuar con el hardware, si tu evitas que tu software “vea” al hardware, este no podrá hacer daño al equipo. Para poner un ejemplo, todos conocemos lo “peligrosos” que son los USB con vírus cuando hablamos de Windows, pues ciertamente los usb pueden contener código en linux que podría o no ser perjudicial para un sistema, si hacemos que el kernel solo reconozca el tipo de usb (firmware) que deseamos, cualquier otro tipo de USB simplemente sería obviado por nuestro equipo, algo ciertamente un poco extremo, pero podría servir dependiendo de las circunstancias.

Servicios

Cuando hablamos de servicios, la primera palabra que me viene a la mente es “supervisión”, y esto es algo bastante importante, puesto que una de las primeras cosas que hace un atacante al entrar a un sistema es mantener la conexión. Realizar análisis periódicos de las conexiones entrantes y sobre todo salientes es algo muy importante en un sistema.

Iptables

Ahora bien, todos hemos oído sobre iptables, es una herramienta que permite generar reglas de ingreso y salida de data a nivel de kernel, esto es ciertamente útil, pero también es un arma de doble filo. Muchas personas creen que por tener el “firewall” ya están libres de cualquier tipo de ingreso o salida del sistema, pero nada más alejado de la realidad, esto solo puede servir de efecto placebo en muchos casos. Es conocido que los firewalls funcionan a base de reglas, y estas ciertamente pueden ser evitadas o engañadas para permitir transportar data por puertos y servicios por los cuales las reglas considerarían que es algo “permitido”, solo es cuestión de creatividad :)

Estabilidad vs rolling-release

Ahora este es un punto bastante polémico en muchos lugares o situaciones, pero permítanme explicar mi punto de vista. Como miembro de un equipo de seguridad que vela por muchos de los problemas de la rama estable de nuestra distribución, estoy al tanto de muchas, casi todas las vulnerabilidades existentes en los equipos Gentoo de nuestros usuarios. Ahora bien, distribuciones como Debian, RedHat, SUSE, Ubuntu y muchas otras pasan por lo mismo, y sus tiempos de reacción pueden variar dependiendo de muchas circunstancias.

Vayamos a un ejemplo claro, seguro todos han oído hablar de Meltdown, Spectre y toda una serie de noticias que han volado por internet en estos días, pues bien, la rama más “rolling-release” del kernel ya está parchada, el problema radica en llevar esas correcciones a kernels anteriores, ciertamente el “backporting” es un trabajo pesado y difícil. Ahora bien, después de eso, todavía tienen que ser probados por los desarrolladores de la distribución, y una vez que se han completado las pruebas, recién estará a disposición de los usuarios normales. ¿A qué quiero llegar con esto? A que el modelo rolling-release nos exige conocer más sobre el sistema y formas de rescatarlo si algo falla, pero eso es bueno, porque mantener la pasividad absoluta en el sistema tiene varios efectos negativos tanto para quien lo administra como para los usuarios.

Conoce tu software

Este es un adicional bastante valioso al momento de administrar, cosas tan simples como subscribirse a las noticias del software que utilizas puede ayudar a conocer de antemano los avisos de seguridad, de esta manera se puede generar un plan de reacción y al mismo tiempo ver cuánto tiempo toma para cada distribución resolver los problemas, siempre es mejor se proactivo en estos temas porque más del 70% de los ataques a empresas se llevan a cabo por software no actualizado.

Reflexión

Cuando la gente habla de hardening, muchas veces se cree que un equipo “resguardado” es a prueba de todo, y no hay nada más falso. Como su traducción literal lo indica, hardening implica hacer las cosas más difíciles, NO imposibles… pero muchas veces mucha gente piensa que esto conlleva magia oscura y muchos trucos como los honeypots… esto es un adicional, pero si no se puede con lo más básico como mantener actualizado un software o un lenguaje de programación… no existe necesidad de crear redes fantasma y equipos con contramedidas… lo digo porque he visto varias empresas donde preguntan por versiones de PHP 4 a 5 (evidentemente descontinuadas)… cosas que hoy por hoy son conocidas por tener cientos sino miles de fallas de seguridad, pero si la empresa no puede seguir el ritmo de la tecnología, pues de nada sirve que hagan lo demás.

Además, si todos estamos usando software libre o abierto, el tiempo de reacción para los errores de seguridad suele ser bastante corto, el problema viene cuando estamos tratando con software privativo, pero eso lo dejo para otro artículo que sigo esperando poder escribir pronto.

Muchas gracias por llegar hasta aquí :) saludos

Published by

ChrisADR

I’m a young developer who loves open source and free software technologies, I’m the founder of CodeLabora, an open source community which aims to help young developers from Latin America to get involved with open source and free software projects and communities around the world.

I like to learn and my favorite subjects are security and Linux. I’ve recently finished an internship as security analyst and contribute to the security project from my Linux community, Gentoo Linux, as Gentoo Linux Security Advise (GLSA) Coordinator

2 thoughts on “cómo proteger tu equipo de ataques”

  1. Muchas gracias por tu aporte!
    Muy interesante, sobre todo la parte del Rolling release.
    No había tomado en cuenta eso, ahora me toca administrar un server con Gentoo para ver las diferencias que tengo con Devuan.
    Un gran saludo y ps a compartir esta entrada en mis redes sociales para que este blog llegue a más personas!!
    Gracias!

    1. Hola Alberto :) muchas gracias, estuve varios días pensando en el post en realidad, no sabía qué escribir que se mantuviera interesante, novedoso y curioso :P pero es cierto, muchas empresas usan el modelo rolling release porque hay un dicho por ahí que dice “si es estable…es vulnerable”. Saludos y gracias por compartirlo :)

Leave a Reply

Your email address will not be published. Required fields are marked *