Seguridad

Luego de configurar un nuevo FileSet para un servidor FreeBSD, me topé con el siguiente mensaje al correr el trabajo de backup por primera vez:

05-dic 13:29 fbsd10-fd JobId 14:      /usr/local/backups/www is a different filesystem. Will not descend from /usr/local/backups into it.

Esto se debe a que, por defecto, el File Deamon de Bacula no atraviesa file systems al momento de realizar un backup. Es decir no resguarda los archivos que se encuentran en un sistema de archivos montado en un subdirectorio.

Un problema que he descubierto recientemente con Bacula, es que el File Deamon en los clientes no sigue links simbólicos que apunten a otro filesystem o a un directorio que no es parte del backup (FileSet, conjunto de archivos a resguardar). Esto es un comportamiento lógico, pues Bacula da precedencia a la configuración de Include y Exclude dentro de cada FileSet. Sin embargo, es un detalle particular a tener en cuenta al momento de definir tanto los FileSet como los trabajos de Backup, pues Bacula no sigue aquellos symlinks que apunten a directorios fuera del conjunto a resguardar.

Este artículo explica cómo hackear una base de datos de MediaWiki para alterar la contraseña de un usuario, sin recurrir al método de restablecimiento por correo electrónico. Durante el proceso se repasan algunos conceptos interesantes como búsqueda de archivos por nombre y contenido; chroot, acceso a bases de datos SQLite, consultas SQL, codificación en Base64, generación de claves utilizando la función PBKDF2, ejecución de código PHP en modo interactivo, y más...

Este artículo muestra cómo correr un script o comando en un cliente de Bacula, justo antes de que comience el trabajo de backup para el mismo. Esto es muy necesario para el caso de los servidores de bases de datos, donde se requiere realizar un volcado (dump) de las bases de datos a disco (por ejemplo mysqldump o pg_dump) para que sean parte de la copia de seguridad.

En este artículo quise demostrar algunos de los ataques que detecta y reporta logwatch a diario, de acuerdo a la información que recoge de los logs de accesos y errores del servidor Nginx, junto con un uso insospechado que recientemente encontré al mismo.

Logwatch es una herramienta indispensable en todos mis servidores. Es la que me permite tener una visión general de la actividad de cada servidor a lo largo del día. Y es la que, junto con AIDE, me permite detectar cualquier actividad sospechosa en los procesos y el filesystem.

Este es otro artículo para generar conciencia respecto a la seguridad de la información, y los peligros que supone poner un servicio a disposición de Internet (en este caso, un sitio Web). Es común que muchos administradores novatos o negligentes se inclinen hacia razonamientos del tipo "a mi no me va a pasar", "quién va a querer atacar mi servidor", u otros similares. Este tipo de argumentos son desacertados porque asumen intencionalidad. Es decir asumen que van a ser víctimas de ataques cuando un individuo quiera provocar específicamente un daño a la reputación de nuestra marca/empresa/cliente/servidor. Tal aseveración es falsa y la realidad es que, en la mayoría de los casos, los atacantes no buscan un daño o prejuicio, sino que simplemente buscan agregar un nodo más a una botnet, sin dejar el más mínimo rastro o daño que los pueda poner en evidencia. Y más aún, la mayoría de los ataques no son dirigidos específicamente a un sitio o servidor, sino que son "al voleo" y con herramientas automáticas. Y en muchos casos llevados a cabo por robots. A quién atacan luego con la botnet, vaya uno a saber. Lo importante es que sea lo más grande posible (en cantidad de nodos o bots).

En definitiva, cuando uno pone a disposición un servicio accesible públicamente, tarde o temprano será atacado. Pues los robots barren constantemente las redes IPv4 e IPv6 en búsqueda de nuevos hosts y puertos abiertos.