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

Sistemas de Administración de Contenidos (CMS)

Guía de seguridad wordpress

Captura desde 2024-06-20 18-19-22.png


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:

AccesoDeUsuarios.png

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”.

ActualizacionDelCore.png

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”.

ActualizacionDePlugins.png

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

ActualizacionDePluginsError.png

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”

ActualizacionesDeSeguridadAutomáticas.png

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:

XMLRPC.png

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.

EnumeracionDeUsuarios.png

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

En ese sentido en WordPress se debe seguir los siguientes pasos


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)

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:

Configuración del Plugin:

Establecimiento de Límites y Acciones:

Personalización de Mensajes y Notificaciones:

Prueba y Verificación:

Monitoreo Continuo y Ajustes:

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:

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_';

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:

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:

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');

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');

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);

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.

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

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

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.


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

Instala un Plugin de Copias de Seguridad:

Configura el Plugin de Copias de Seguridad:

Crea un Nuevo Trabajo de Copia de Seguridad:

Selecciona Qué Incluir en la Copia de Seguridad:

Configura la Frecuencia y Horario:

Elige el Destino de la Copia de Seguridad:

Configura Opciones Avanzadas (si es necesario):

Guarda y Activa el Trabajo de Copia de Seguridad:

Prueba y Verifica:

Monitoriza y Mantén:

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 


Sistemas de Administración de Contenidos (CMS)

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:

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

SeguridadJoomla.png

VerificarVulnerabilidades.png

Known vulnerabilities.png

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

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

ConfiugraciondeUsusario.png

Options.png

EstablecerCOntraseña.png

GuardaryCerrar.png

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.

$ sudo nano /etc/apache2/apache2.conf
<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>
$ sudo service apache2 restart
<FilesMatch “configuration.php”>
	Require all denied
</FilesMatch>

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:

$ sudo mkdir miotroadm
$ cd miotroadm
$ sudo nano index.php
<?php
	$admin_cookie_code="1254789654258"
	setcookie("JoomlaAdminSession",$admin_cookie_code,0,"/");
	header("Location: ../administrator/index.php");
?>
$ sudo nano administrator/index.php
if($_COOKIE['JoomlaAdminSession']!="1254789654258")
{
	setcookie('JoomlaAdminSession', null, -1, '/');
	header("Location: ../../index.php");
}
$ 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”:

SEF.png

2.7. Realizar copia de seguridad

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

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

RealizarCopiaDeSeguridad.png

DefaultBackupProfile.png

DespliegueBackup.png

ManageBackups.png

BackupsGenerados.png

 

Sistemas de Administración de Contenidos (CMS)

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:

Estos valores luego obtendrían resultados como los siguientes:

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.

MensajeDeErrorLogin.png

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
  1. Instalar y activar el complemento.
    1. Ir a ‘Plugins > Add New’ en el panel de administración.
    2. Buscar ‘WP-Hardening’
    3. Instalar WP-Hardening una vez que aparezca.
    4. Activarlo desde su página Plugins.
    5. El botón WP-Hardening aparecerá en la parte inferior izquierda de su panel de administración.

  2. Ir a la pestaña 'Security Fixers'
    SecurityFixers.png
  3. Mover la tecla junto a "Stop User enumeration"
    StopUserEnumeration.png
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.

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.

<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');

EliminacionLosMensajesDeError.png

Servidores de correo

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

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.

ORM1.png

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

ORM2.png

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

ORM3.png

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:

ORM4.png

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?

ORM5.png

Comprobar si tenemos configurado SPF en nuestro dominio:

https://mxtoolbox.com/SuperTool.aspx

ORM6.png

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:

ORM7.png

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

ORM8.png

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

ORM9.png

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:

ORM10.png

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

ORM11.png


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:

ORM12.png

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

ORM13.png

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



Servidores de correo

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

Servidores de Nombres de Dominio (DNS)

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/

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.

Software de propósito general

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

Instalación

history -c
echo "set +o history" >> ~/.bashrc
unzip vault-XYZ.zip
chown root:root vault
mv vault /usr/local/bin/
rm -f vault-XYZ.zip
vault -autocomplete-install
sudo mkdir /etc/vault
sudo mkdir -p /var/lib/vault/data
sudo useradd --system --home /etc/vault --shell /bin/false vault
sudo chown -R vault:vault /etc/vault /var/lib/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
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
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.

export VAULT_ADDR=https://127.0.0.1:8200
echo "export VAULT_ADDR=https://127.0.0.1:8200" >> ~/.bashrc
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

vault operator unseal
vault login <<token root>> 
vault audit enable syslog tag="vault" facility="AUTH"
apt-get install syslog-ng
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

vault secrets enable -version=1 kv
vault secrets list 
vault kv put kv/apikey/Google llave=AAaaBBccDDeeOTXzSMT1234BB_Z8JzG7JkSVxI
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']
vault kv put kv/cert/mysql certificado=@cert.pem
vault kv get -field=certificado kv/cert/mysql

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

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
setcap cap_ipc_lock=+ep /etc/vault/plugins/vault-secrets-gen
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
vault secrets enable \
    -path="gen" \
    -plugin-name="secrets-gen" \
    plugin
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

vault secrets enable database
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"
vault write database/roles/my-role \
    db_name=my-mongodb-database \
    creation_statements='{ "db": "admin", "roles": [{ "role": "readWrite" }] }' \
    default_ttl="1h" \
    max_ttl="24h"
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:

  1. Tiempo de vida
  2. Permiso granular de acceso a Vault
  3. 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
  1. Tiempo de vida del token 10 minutos
  2. Tiempo de vida del secret-id 1 minuto
  3. 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
vault read auth/approle/role/databaseApp
vault read auth/approle/role/databaseApp/role-id
vault write -f auth/approle/role/databaseApp/secret-id
vault write auth/approle/login role_id="XXXXX" secret_id="YYYYYYY"
vault token revoke s.V6T0DxxIg5FbBSre61y1WLgmalid

Hardening

Redes sociales

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

Redes sociales

Ajustes de seguridad y privacidad en redes sociales

Twitter

Facebook

Instagram

Servicios de Google (YouTube, Gmail, etc)

En general

Redes sociales

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:

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:

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:

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:

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
5.1.2. Verificación de la cuenta

Para verificar la cuenta se debe realizar las siguientes acciones:

5.1.3. Desvinculación del personal
5.2. Habilitar características de seguridad
5.2.1. 2FA
5.2.2. Notificación de alertas de seguridad
5.2.3. Establecer roles y permisos

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.

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

Wazuh - Open Source XDR. Open Source SIEM

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:

Estabilidad y rendimiento:

Nuevos paquetes y versiones:

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: 

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: 

image.png

Compatibilidad del navegador.

Se admiten los siguientes navegadores web:

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

image.png

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. 

image.png

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:

image.png

image.png

image.png

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

image.png

image.png

Actualizamos el navegador y tenemos al agente desplegado.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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.

image.png

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.

image.png

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

image.png

sudo systemctl status wazuh-dashboard

image.png

sudo systemctl status wazuh-indexer

image.png

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

image.png

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.

image.png

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

image.png

sudo systemctl status wazuh-dashboard

image.png

sudo systemctl status wazuh-indexer

image.png

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.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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:

image.pngWazuh 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.

image.png

Resultados.

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

image.png

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.

image.png

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

image.png

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

image.png

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.

image.png

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:

image.png

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

image.png

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.

image.png

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.

image.png

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:

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:

image.png

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.

image.png

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.

image.png

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:

image.png

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.

image.png

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:

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:

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

image.png

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 

image.png

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
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.

image.png

Se realizo una detección de un posible rootkit.

image.png

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.

image.png

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.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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:

image.png

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>

image.png

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.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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.

image.png

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.

image.png

image.png

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:

image.png

En el caso del comando userdel tenemos:

image.png

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:

image.png

Realizamos la prueba en Decoders Test para verificar que se reconocen los parámetros.

image.png

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.

image.png

Una vez realizada esta regla probamos el log con Ruleset Test de Wazuh para ver si se genera de manera correcta.

image.png

Realizadas las pruebas utilizaremos la maquina virtual para proceder con la generación de alertas de niveles 8 y 10 respectivamente:
Usuario creado:

image.png

Escala de privilegios:

image.png

Eliminación de usuario:

image.png

En el agente de Wazuh agregamos este bloque en el archivo de configuración para monitorizar el archivo sudoers.

image.png

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:

image.png

Las reglas se modificaron de la siguiente manera:

Wazuh - Open Source XDR. Open Source SIEM

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.

image.png

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 “-”.

image.png

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:

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.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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:

image.png

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:

image.png

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

image.png

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

image.png

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

image.png

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

image.png

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

image.png

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

image.png

Por ultimo verificamos el archivo syslog para confirmar que la información este correlacionada.

image.png

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.

image.png

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:

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.

image.png  image.png

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.

image.png    image.png

Posteriormente observamos la alerta en Wazuh manager.

image.png

Posteriormente podemos realizar una regla mas en caso de que se elimine una tabla dentro de una base de datos:

image.png

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.

image.png

Wazuh - Open Source XDR. Open Source SIEM

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:

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

image.png

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:

image.png

Cuando se detecta un archivo infectado tenemos:

image.png

Cuando se tiene un error inesperado o mala configuración tenemos:

image.png

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.

Wazuh - Open Source XDR. Open Source SIEM

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.

Wazuh - Open Source XDR. Open Source SIEM

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:

Wazuh - Open Source XDR. Open Source SIEM

Comprobación de Seguridad en WordPress con Wazuh

Introducción

En esta guía, aprenderás a configurar y utilizar Wazuh para comprobar la seguridad de una instalación de WordPress. Wazuh es una plataforma de seguridad de código abierto que permite realizar comprobaciones de la configuración de seguridad (SCA, Security Configuration Assessment) con el objetivo de identificar vulnerabilidades y configuraciones incorrectas en tu sitio de WordPress.

El uso de SCA en Wazuh facilita la detección de configuraciones débiles, permisos inadecuados, credenciales expuestas y otras fallas de seguridad que pueden comprometer un sitio web. A lo largo de esta guía, se explicarán los pasos necesarios para la instalación y configuración de Wazuh, la implementación del agente en el servidor donde se ejecuta WordPress y la correcta integración con WP-CLI, herramienta clave para gestionar WordPress desde la línea de comandos.

Requisitos Previos

Antes de comenzar, asegúrate de contar con los siguientes requisitos:

  1. Un servidor con WordPress instalado.
  2. Acceso root o permisos de administrador en el servidor.
  3. Docker instalado (si optas por la versión en contenedores de Wazuh).
  4. WP-CLI instalado en el servidor (herramienta de línea de comandos para administrar WordPress).

Instalación de Wazuh

Opción 1: Instalación en Docker

Si prefieres instalar Wazuh utilizando Docker, sigue estos pasos:

git clone <https://github.com/wazuh/wazuh-docker.git> -b v4.9.2
cd wazuh-docker/single-node
sudo docker compose -f generate-indexer-certs.yml run --rm generator
sudo docker compose up -d
https://localhost   #credenciales por defecto  admin:SecretPassword

image.png

Opción 2: Instalación mediante script de la documentación.

Si prefieres instalar Wazuh de manera manual, sigue la guía oficial proporcionada por la AGETIC:

Debes tomar en cuenta la recomendación de instalar siempre la última versión disponible de Wazuh y comenzar con la instalación con privilegios de root o un usuario sudo.

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:

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
wp --info

Si la instalación fue exitosa, deberías ver la versión de WP-CLI reflejada en la salida del comando.

Creación de Políticas de Seguridad para WordPress

Paso 1: Crear el Archivo de Políticas

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
# 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:
  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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

  - 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
    rules:
      - c:curl -s -o /dev/null -w "%{http_code}" $wp_host/xmlrpc.php -> r:^(200|403)$
  - 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:.*

Este archivo establecerá las configuraciones que serán revisadas por Wazuh, como permisos de archivos, configuración de autenticación, cada regla tiene su información acerca de su funcionamiento en el apartado "description".

Paso 2: 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.

wget <https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb>
sudo dpkg -i wazuh-agent_4.9.2-1_amd64.deb
sudo apt --fix-broken install
sudo nano /var/ossec/etc/ossec.conf

image (1).png

<policies>
    <policy>/home/local_sca_policies/custom_wordpress_policy.yml</policy>
</policies>

image (2).png

/var/ossec/bin/wazuh-control restart

image (3).png

Verificación de Resultados

Una vez configurado el análisis de seguridad en Wazuh, puedes verificar los resultados desde la interfaz gráfica.

image (4).png

image (5).png

image (6).png

Con esta guía, has aprendido a instalar y configurar Wazuh para comprobar la seguridad de una instalación de WordPress. Implementando las políticas de seguridad adecuadas y utilizando WP-CLI, puedes obtener información detallada sobre posibles vulnerabilidades y corregirlas a tiempo para fortalecer la seguridad de tu sitio.

Para obtener más información sobre la configuración avanzada de Wazuh, consulta la documentación oficial.

Recomendaciones.

Wazuh - Open Source XDR. Open Source SIEM

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:

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

<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

<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

<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

<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

<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

<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>