En el siguiente articulo veremos como implementar un Security Incident Response Platform (SIRP) basado en software open source en alta disponibilidad.
Como podemos ver en el diagrama, el agente de Wazuh HIDS envía los datos de todos los servidores a Wazuh Manager y ElasticSearch. ElastAlert observará los nuevos eventos y generará alertas en TheHive.
Componentes:
NGINX
Nginx es un servidor web/proxy inverso ligero de alto rendimiento con el cual proporcionaremos un balanceo de carga en el Cluster de Wazuh.
Wazuh
Wazuh es una solución de monitorización de seguridad basada en open source que recopila y analiza los datos de seguridad de un servidor.
Elasticsearch
Elasticsearch Se trata de un motor de búsqueda y análisis. Es distribuible y fácilmente escalable, enfocado sobre todo al mundo empresarial y científico. actuará como nuestro repositorio de registro.
AlastAlert
AlasAlert es un proyecto open source iniciado que nos proporciona un mecanismo de alerta para elasticsearch
TheHive
TheHive será nuestra plataforma de respuesta ante incidentes de seguridad. Es donde administraremos todas las alertas.
Cortex
Cortex es otro productos del mismo equipo de TheHive el cual lo complomenta. Mediante Cortex analizaremos la información sobre los indicadores que ya están presentes en los registros.
MISP
MISP es una plataforma de distribución de amenazas open source mantenida por CIRCL que, entre muchos otros usos permite al operador suscribirse a las fuentes de inteligencia de amenazas.
Instalación y configuración Load balancer
Para no alargar mucho el manual no vamos a poner en está entrada como instalar el Load balancer, para ello podemos consultar la siguiente entrada: Nginx high availability en FreeBSD con CARP y Monit
Configurar balanceo de carga
Para llevar a cabo la configuración debemos tener activado el modulo de Stream, en mi caso he generado un directorio donde depositar todos los sitios de Stream. Agregamos las siguientes lineas en /etc/nginx/nginx.confg
stream {
include /etc/nginx/streams-enabled/*;
}
Una vez tenemos configurado todos los componentes de nuestro balanceador, añadirnos en /etc/nginx/streams-enabled/wazuh.conf el balanceo al cluster de wazuh
upstream cluster {
hash $remote_addr consistent;
server 192.168.4.155:1514; #Master
server 192.168.4.156:1514; #Worker
server 192.168.4.157:1514; #Worker
}
upstream master {
server 192.168.4.155:1515; #Master
}
server {
listen 1514;
proxy_pass cluster;
}
server {
listen 1515;
proxy_pass master;
}
Reiniciamos el servicio
service nginx restart
Comprobamos que el puerto 1514 este inciado
# netstat -anb | grep 1514
tcp4 0 0 *.1514 *.* LISTEN
Instalación y configuración de Wazuh Cluster
instalamos todos los paquetes necesarios para la instalación de wazuh server
apt install curl apt-transport-https lsb-release gcc g++ make nodejs yarn
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add --
echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt update
Instalamos wazuh-manager y su api
apt install wazuh-manager
curl -sL https://deb.nodesource.com/setup_10.x | bash --
apt install nodejs wazuh-api
Generamos un usuario para la API
cd /var/ossec/api/configuration/auth/
node htpasswd -c user redorbita
Instalamos FileBeats
curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add --
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.lis
apt update
apt install filebeat=7.1.0
Agregamos la configuración de filebeats para nuestra versión de wazuh, en este caso es la 3.9
curl -so /etc/filebeat/filebeat.yml https://raw.githubusercontent.com/wazuh/wazuh/v3.9.1/extensions/filebeat/7.x/filebeat.yml
A continuación debemos agregar los nodos de nuestro cluster de elasticsearch
output.elasticsearch:
hosts: ['http://192.168.4.160:9200', 'http://192.168.4.161', 'http://192.168.4.162']
#pipeline: geoip
indices:
- index: 'wazuh-alerts-3.x-%{+yyyy.MM.dd}'
También nos dan la opción de enviarlo por logstash como en versiones anteriores.
output.logstash.hosts: ["192.168.4.160:5000", "192.168.4.161:5000", "192.168.4.162:5000"]
Descargamos el template para elastic
curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/v3.9.1/extensions/elasticsearch/7.x/wazuh-template.json
Configuración Cluster de Wazuh
Debemos generar una clave de 32 digitos, para ello utilizamos openssl
openssl rand -hex 16
bf292f9a466b151078f5285d0bc4d022
Primero, configuraremos los nodos workers, para ello debemos editar el archivo de configuración (/var/ossec/etc/ossec.conf) y nos vamos a <cluster></cluster>
<cluster>
<name>wazuh</name>
<node_name>redorbita-wazuhdata02</node_name>
<node_type>worker</node_type>
<key>bf292f9a466b151078f5285d0bc4d022</key>
<port>1516</port>
<bind_addr>0.0.0.0</bind_addr>
<nodes>
<node>192.168.4.155</node>
</nodes>
<hidden>no</hidden>
<disabled>no</disabled>
</cluster>
Una vez configurado todos los nodos de nuestro cluster, pasamos a configurar el nodo master
<cluster>
<name>wazuh</name>
<node_name>redorbita-wazuhmrg01</node_name>
<node_type>master</node_type>
<key>bf2b2f9a466b150078f5985d0bc4d065</key>
<port>1516</port>
<bind_addr>0.0.0.0</bind_addr>
<nodes>
<node>192.168.4.155</node>
</nodes>
<hidden>no</hidden>
<disabled>no</disabled>
</cluster>
Para que los clientes se puedan conectar utilzando el balanceador debemos modificar en el apartado <auth></auth> la linea use_source_ip
<use_source_ip>no</use_source_ip>
También debemos modificar para utilizar TCP en vez de UDP en el puerto 1514
<remote>
<connection>secure</connection>
<port>1514</port>
<protocol>tcp</protocol>
<queue_size>131072</queue_size>
</remote>
Iniciamos los servicios y lo configuramos para que cuando arranque el servicio inicien automáticamente.
systemctl daemon-reload
systemctl enable filebeat.service
systemctl enable wazuh-api
systemctl enable wazuh-manager
systemctl start wazuh-manager
systemctl start wazuh-api
systemctl start filebeat.service
Comprobamos que a iniciado correctamente el cluster
/var/ossec/bin/cluster_control -l
NAME TYPE VERSION ADDRESS
redorbita-wazuhmrg01 master 3.9.0 192.168.4.155
redorbita-wazuhdata02 worker 3.9.0 192.168.4.156
redorbita-wazuhdata03 worker 3.9.0 192.168.4.157
También podemos consultar la información del cluster mediante la API
curl -u foo:bar -X GET "http://localhost:55000/cluster/nodes?pretty"
{
"error": 0,
"data": {
"totalItems": 3,
"items": [
{
"name": "redorbita-wazuhmrg01",
"type": "master",
"version": "3.9.0",
"ip": "192.168.4.155"
},
{
"name": "redorbita-wazuhdata02",
"type": "worker",
"version": "3.9.0",
"ip": "192.168.4.156"
},
{
"name": "redorbita-wazuhdata03",
"type": "worker",
"version": "3.9.0",
"ip": "192.168.4.157"
}
]
}
}
Una vez comprobado que funciona correctamente, vamos a configurar el servicio de SYSLOG remoto, para ello editamos /va/ossec/etc/ossec.conf y agregamos la siguientes lineas
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>192.168.4.4</allowed-ips>
</remote>
También en la sección <global></global> debemos activar logall
<logall>yes</logall>
Reiniciamos el servicio
/var/ossec/bin/ossec-control restart
Instalación Cluster Elastic
A continuación, comenzaremos la instalación del cluster de Elasticsearch el cual contará con un nodo master y dos de datos.
Instalamos las dependencias de Elastic
apt install dirmngr default-jre curl apt-transport-https
Configuramos el repositorio de Elastic
curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list
apt update
Instalamos Elastic
apt install elasticsearch=7.1.0
Configuramos el cluster de Elastic, el cual contará con tres nodos. Para ello debemos de modificar el siguiente archivo de configuración: /etc/elasticsearch/elasticsearch.yml
cluster.name: cluster-elastic
node.name: ${HOSTNAME}
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["192.168.4.160", "192.168.4.161", "192.168.4.162", "192.168.4.158"]
cluster.initial_master_nodes: ["192.168.4.160", "192.168.4.161", "192.168.4.162"]
gateway.recover_after_nodes: 3
Configuramos el servicio al inicio e iniciamos
systemctl daemon-reload
systemctl enable elasticsearch.service
systemctl start elasticsearch.service
Comprobamos que funciona correctamente
curl "http://localhost:9200/?pretty"
{
"name" : "redorbita-elasticmrg01",
"cluster_name" : "cluster-elastic",
"cluster_uuid" : "_na_",
"version" : {
"number" : "6.7.2",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "56c6e48",
"build_date" : "2019-04-29T09:05:50.290371Z",
"build_snapshot" : false,
"lucene_version" : "7.7.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
Comprobamos el esado del cluster
curl http://localhost:9200/_cat/health
1558094516 12:01:56 cluster-elastic green 3 3 0 0 0 0 0 0 - 100.0%
También lo podemos probar de la siguiente forma.
curl "http://localhost:9200/_cluster/state?pretty"
Instalamos logstash
En esta versión de wazuh no necesitamos logstash, pero nosotros lo vamos a dejar preparado dado que podemos enviar alertas desde firewall o otros dispositivos de seguridad.
apt install logstash
Instalamos el plugin de wazuh en logstash, dado que nosotros estamos utilizando una arquitectura distribuida instalamos el siguiente plugin:
curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/logstash/01-wazuh-remote.conf
En caso de ser en un unico servidor se instalaría el siguiente:
curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/logstash/01-wazuh-local.conf
Configuramos en el output de logstash nuestros nodos de elasticserch en el archivo de configuración: /etc/logstash/conf.d/01-wazuh.conf
output {
elasticsearch {
hosts => ["192.168.4.160:9200", "192.168.4.161:9200", "192.168.4.162:9200"]
index => "wazuh-alerts-3.x-%{+YYYY.MM.dd}"
document_type => "wazuh"
}
}
Reiniciamos y agregamos el servicio al inicio
systemctl daemon-reload
systemctl enable logstash.service
systemctl start logstash.service
Instalación Kibana
Bajo este servidor vamos a instalar el cliente de elastic y kibana.
Instalamos las dependencias de Elastic
apt install dirmngr default-jre curl apt-transport-https
Configuramos el repositorio de Elastic
curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list
apt update
Instalamos Elastic
apt install elasticsearch=7.1.0
Configuramos en modo cliente elastic, para ello modificamos las siguientes lineas en: /etc/elasticsearch/elasticsearch.yml
cluster.name: cluster-elastic
node.master: false
node.data: false
node.ingest: false
node.name: ${HOSTNAME}
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["192.168.4.160", "192.168.4.161", "192.168.4.162", "192.168.4.158"]
discovery.seed_hosts: ["192.168.4.160", "192.168.4.161", "192.168.4.162"]
gateway.recover_after_nodes: 3
Configuramos el servicio al inicio y lo iniciamos
systemctl daemon-reload
systemctl enable elasticsearch.service
systemctl start elasticsearch.service
Comprobamos de nuevo el estado del cluster desde el nodo cliente
curl -X GET "localhost:9200/_cluster/health"
{"cluster_name":"cluster-elastic","status":"green","timed_out":false,"number_of_nodes":4,"number_of_data_nodes":4,"active_primary_shards":8,"active_shards":12,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":0,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":100.0}
Instalamos Kibana
apt install kibana=7.1.0
Instalamos el plugin de wazuh en Kibana
sudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-3.9.1_7.1.0.zip
Configuramos el direccionamiento por donde va a escuchar Kibana, la configuración de Kibana la podemos encontrar en: /etc/kibana/kibana.yml
server.host: "0.0.0.0"
elasticsearch.requestTimeout: 300000
Agregamos Kibana al inicio y lo iniciamos
systemctl enable kibana
systemctl start kibana
Una vez haya iniciado Kibana accedemos mediante nuestro navegador por el puerto 5601
Tras cargar la aplicación nos vamos a la sección de wazuh y configuramos la API para la conexión entre Kibana y wazuh
Instalación Wazuh Agent
Instalamos los paquetes necesario
apt install curl apt-transport-https lsb-release
Agregamos la key del repositorio
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
Agregamos el repositorio y actualizamos en Debian
echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt update
Agregamos el repositorio en Redat
rpm --import http://packages.wazuh.com/key/GPG-KEY-WAZUH-5
cat > /etc/yum.repos.d/wazuh.repo <<\EOF
[wazuh_repo]
gpgcheck=1
gpgkey=http://packages.wazuh.com/key/GPG-KEY-WAZUH-5
enabled=1
name=Wazuh repository
baseurl=http://packages.wazuh.com/3.x/yum/5/$basearch/
protect=1
EOF
Instalamos el agente en Debian
apt install wazuh-agent
Instalamos el agente en Redhat
yum install wazuh-agent
Nos vamos al servidor que tiene el rol maestro de wazuh manager, ejecutamos /var/ossec/bin/manage_agents y seleccionamos la opción A
Agregamos el nombre del servidor y en caso que vayamos desde el balanceador ANY
Nos devuelve al menu principal y seleccionamos la opción E para extraer la key
Volvemos al cliente donde hemos instalado el Wazuh y editamos el fichero de configuración /var/ossec/etc/ossec.conf
En este fichero de configuración en el apartado de client debemos configurar la IP virtual de nuestro balanceador configurado anteriormente
<client>
<server>
<address>VIP LOAD BALANCER</address>
<port>1514</port>
<protocol>tcp</protocol>
</server>
<config-profile>debian, debian9</config-profile>
<notify_time>10</notify_time>
<time-reconnect>60</time-reconnect>
<auto_restart>yes</auto_restart>
<crypto_method>aes</crypto_method>
</client>
Una vez configurado, ejecutamos /var/ossec/bin/manage_agents y seleccionamos la opción I para importar la key generada anteriormente en el servidor de wazuh manager
Reiniciamos el servicio
/etc/init.d/wazuh-agent restart
Nos vamos a la consola de Kibana > Wazuh > Agents y comprobamos que nuestro agente esta activo
Instalación de Thehive y Elasticsearch 5.6
A continuación vamos a instalar el servidor de Thehive, para ello agregamos los repositorios con sus respectivas Keys
apt install dirmngr apt-transport-https
echo 'deb https://dl.bintray.com/thehive-project/debian-stable any main' | sudo tee -a /etc/apt/sources.list.d/thehive-project.list
echo "deb https://artifacts.elastic.co/packages/5.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-5.x.list
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
curl https://raw.githubusercontent.com/TheHive-Project/TheHive/master/PGP-PUBLIC-KEY | apt-key add -
Actualizamos e instalamos Java
apt update
apt install openjdk-8-jre
Instalamos y configuramos Elasticsearch
apt install elasticsearch
Modificamos las siguientes lineas en /etc/elasticsearch/elasticsearch.yml
cluster.name: hive
bootstrap.memory_lock: true
discovery.type: single-node
Iniciamos el servicio y lo agregamos al inicio
systemctl daemon-reload
systemctl enable elasticsearch
systemctl start elasticsearch
Comprobamos que responde
curl http://localhost:9200
{
"name" : "gOK4ASj",
"cluster_name" : "thehive",
"cluster_uuid" : "elA6mKL8S9WcwM-6VtcO7w",
"version" : {
"number" : "5.6.16",
"build_hash" : "3a740d1",
"build_date" : "2019-03-13T15:33:36.565Z",
"build_snapshot" : false,
"lucene_version" : "6.6.1"
},
"tagline" : "You Know, for Search"
}
Instalamos TheHive
apt install thehive
Editamos /etc/thehive/application.conf y agregamos una contraseña
play.http.secret.key="TU CONTRASEÑA"
Iniciamos el servicio y lo agregamos al inicio
systemctl daemon-reload
systemctl enable thehive
systemctl start thehive
Accedemos mediante nuestro navegador a http://TheHiveIP:9000
Nos debería aparecer un mensaje similar a este:
Presionamos a actualizar, en caso de que no nos haya aparecido esta pantalla y nos muestre un formulario de Login debemos revisar la configuración de thehive o elastic.
Una vez actualizada la base de datos, nos mostrará un formulario para la configuración del usuario y contraseña
Instalar Cortex
apt install cortex=2.1.3-1
Instalamos todas los requisitos de cortex
apt install -y --no-install-recommends python-pip python2.7-dev python3-pip python3-dev ssdeep libfuzzy-dev libfuzzy2 libimage-exiftool-perl libmagic1 build-essential git libssl-dev
pip install -U pip setuptools && pip3 install -U pip setuptools
Clonamos el proyecto de Cortex-Analyzers en /etc/cortex
cd /etc/cortex
git clone https://github.com/TheHive-Project/Cortex-Analyzers
Otorgamos los permisos correctos
chown -R root:cortex Cortex-Analyzers
instalamos todas las dependencias de Analyzers
for I in $(find Cortex-Analyzers -name 'requirements.txt'); do sudo -H pip2 install -r $I; done && \
for I in $(find Cortex-Analyzers -name 'requirements.txt'); do sudo -H pip3 install -r $I || true; done
Una vez finalizado, accedemos a /etc/cortex/application.conf y debemos de modificar la contraseña y el path de Analyzers
play.http.secret.key="TU CONTRASEÑA"
Nos bajaamos hasta abajo, y en apartado de ##ANALYZERS modificamos el PATH
analyzer {
# Absolute path where you have pulled the Cortex-Analyzers repository.
path = ["/etc/cortex/Cortex-Analyzers/analyzers"]
Reiniciamos el servicio
systemctl enable cortex
systemctl start cortex
Mediante nuestro navegador accedemos http://CortexIP:9001
Nos debería aparecer un mensaje similar a este:
Presionamos a actualizar, en caso de que no nos haya aparecido esta pantalla y nos muestre un formulario de Login debemos revisar la configuración de cortex
Una vez actualizada la base de datos, nos mostrará un formulario para la configuración del usuario y contraseña
Tras iniciar sesión, creamos una organización, para ello presionamos + Add organization
Accedemos a la organización creada y creamos un usuario en ella en + Add user
Debemos crearla con el rol de orgadmin
Una vez creado, debemos configurar una contraseña en New Password
Ahora debemos de cerrar sesión y abrir con el nuevo usuario creado. si todo a salido bien, al irnos a Organization > Analyzers veremos los dispositivos que podemos activar
Habitamos de momento los siguientes:
Abuse_Finder_2_0
CyberCrime-Tracker_1_0
Cyberprotect_ThreatScore_1_0
DShield_lookup_1_0
MISP_2_0
URLhaus_2_0
Urlscan_io_Search_0_1_0
El único que necesita configuración de la API es MISP, el cual veremos a después como integrarlo.
Creamos un nuevo usuario para integrar cortex con thehive, con rol read & analyze. para ello nos vamos de nuevo a Organization > + Add User
En esta ocasión en ves de crear una contraseña debemos de presionar e: Create API key y copiamos la KEY
Vamos a realizar una pequeña prueba, para ello presionamos en + New Analysis en la parte superior
Configuramos el análisis de la siguiente forma y presionamos a start
Si ahora vamos vamos al historial de trabajos podemos ver el análisis ejecutado
Ahora que hemos comprobado el correcto funcionamiento de Cortex vamos a integrarlo con TheHive, para ello editamos el fichero /etc/thehive/application.conf
En la sección de #Cortex descomentamos:
play.modules.enabled += connectors.cortex.CortexConnector
Agregamos la KEY generado anteriormente en la configuración de la API
play.modules.enabled += connectors.cortex.CortexConnector
cortex {
"CORTEX-SERVER-ID" {
url = "http://127.0.0.1:9001"
key = "AAAPI3cRjHQuNSsA"
# # HTTP client configuration (SSL and proxy)
# ws {}
}
}
Reiniciamos el servidor.
Tras el reinicio del servidor accedemos a TheHive y abrimos un caso para comprobar la integración con Cortex, para ello nos vamos a + New case en la parte superior izquierda
Una vez creada nos vamos Observables > + Add Observable(s)
Si hacemos doble click en la dirección ipde observables nos muestra toda la información
Presionamos en la pestaña Run all
Si regresamos a Cortex, en el apartado de Jobs history podemos ver todos los análisis realizados
Si volvemos de nuevo a TheHive en el apartado de Observables de nuestro caso abierto de prueba podemos ver que nos da información sobre todos los procesos analizados
Importar plantillas de informes
Nos descargamos los templates: https://dl.bintray.com/thehive-project/binary/report-templates.zip
iniciamos sesión en TheHive con una cuenta de administrador, nos vamos a Admin > Report templates
Presionamos en Import templates
Importamos los templates descargados anteriormente
Ahora si nos vamos nuevamente a Observables y presionamos sobre el ultimo link podemos ver el informe
Instalación MISP
Implementaremos MISP bajo docker dado que es mucho mas sencillo de instalare, para instalar docker podemos seguir la siguiente guía: https://docs.docker.com/install/linux/docker-ce/debian/
Clonamos el repositorio con la imagen de MISP
git clone https://github.com/harvard-itsecurity/docker-misp.git
cd docker-misp/
Editamos el fichero build.sh y cambiamos la contraseña de root y de la BBDD
#!/bin/bash
docker rmi harvarditsecurity/misp
docker build \
--rm=true --force-rm=true \
--build-arg MYSQL_MISP_PASSWORD=ChangeThisDefaultPassworda9564ebc3289b7a14551baf8ad5ec60a \
--build-arg POSTFIX_RELAY_HOST=localhost \
--build-arg MISP_FQDN=misp.red-orbita.com \
--build-arg MISP_EMAIL=admin@localhost \
--build-arg MISP_GPG_PASSWORD=ChangeThisDefaultPasswordXuJBao5Q2bps89LWFqWkKgDZwAFpNHvc \
-t harvarditsecurity/misp container
Tambien debemos editar el fichero Dockerfile, que se encuentra en la ruta /docker-misp/container
ARG MYSQL_MISP_PASSWORD=ChangeThisDefaultPassword
ARG POSTFIX_RELAY_HOST=127.0.0.1
ARG MISP_FQDN=misp.red-orbita.com
ARG MISP_EMAIL=admin@localhost
ARG MISP_GPG_PASSWORD=ChangeThisDefaultPassworda
Una vez configurado todo, ejecutamos el script build.sh (esto puede tardar varios minutos)
./build.sh
Comprobamos que se hayan desplegado las imágenes
Iniciamos la base de datos y arrancamos el contenedor
docker run -it --restart=always \
-v /docker/misp-db:/var/lib/mysql \
harvarditsecurity/misp /init-db
docker run -it --restart=always -d \
-p 443:443 \
-p 80:80 \
-p 3306:3306 \
-v /docker/misp-db:/var/lib/mysql \
harvarditsecurity/misp
Comprobamos que haya iniciado correctamente
Accedemos utilizando el FQDN configurado anteriormente, si todo a salido bien nos debería mostrar un formulario de login
Accedemos utilizando las siguientes credenciales:
Login: admin@admin.test
Password: admin
Una vez iniciado sesión nos indica que cambiemos la contraseña
Tras el cambio de contraseña nos vamos Administration/Server Settings & Maintenance/ MISP/live. Deberemos
Nos vamos a Sync Actions > List Feeds
Seleccionamos la suscripción que queremos y presionamos en Enabled selected
Una vez activada nos vamos a la derecha y presionamos en el icono con un circulo y una flecha hacia abajo (Fetch all events)
Si nos vamos a Administration > Jobs vemos una tarea ejecutandose
Vamos a probar la API con Postman, para ello nos descargamos la aplicación y la ejecutamos.
Una ve instalada nos vamos a Setting
Desactivamos la verificación de certificado SSL
Nos vamos a MISP y copiamos la Authkey del usuario en Administration > List users
En Postman nos vamos a la pestaña Headers y escribimos los siguientes encabezados allí
Accept application/json
Contect-Type application/json
Authorization <API_Key COPIADA ANTERIORMENTE
Nos vamos a la pestalla de Body y tenemos que cambiar Raw por JSON
Si todo a funcionado correctamente nos debería devolver algo similar a esto:
Una vez comprobado que funciona vamos vamos nuevamente a Sync Action > List Feed y activamos algunas Feed mas, en mi caso he activado
CIRCL OSINT Feed MISP
Por ultimo nos vamos a Administration > Scheduled Task y presionamos a Update All
Integración MISP con Cortex
En la web de MISP nos vamos a Administration > Add User
Creamos el usuario teniendo en cuenta:
Email: cortex@admin.test
Organización: ORGNAME
Role: User
Deseleccionamos todos los box de la parte inferior.
Nos vamos a Cortex > Organization > Analyzers, buscamos MISP_2_0 y acivamos
Agregamos una breve descripción, la URL de nuestro servidor, el AuthKey del usuario creado anteriormente el MISP y desactivamos el chequeo del del certificado.
Nos amos ahora nuevamente a MISP > Sync Actions > List Feeds > y presionamos sobre la lupa de uno de los Feed que hemos activado anteriormente
Copiamos una IP de la lista
De nuevo nos vamos a Cortex, presionamos en + New Analysis > seleccionamos MISP_2_0 y copiamos la IP seleccionada de la lista
Nos vamos a Job History y si todo a salido bien deberíamos ver el análisis de la IP
Ahora abriremos un Observable en TheHive para comprobar la integración desde aquí también, para ello + New Case
Nos vamos a la pestaña Observables > Add Obsevables y agregamos la misma IP que en el caso anterior
Accedemos al caso y ejecutamos sobre MISP_2_0
En la consola de Jobs de Cortex podemos encontrar el análisis
Instalación de ElastAlert
Para terminar toda la integración de la infraestructura con la instalación de ElastAlert, el cual nos proporcionará la integración de Elasticsearch y Thehive
ElasticAlert se puede instalar o en un servidor independiente o en uno de los nodos del cluster de Elastic, en mi casó lo voy a instalar dentro de uno de los servidores del cluster de Elastic.
apt install python-pip libffi-dev libxml2-dev libxslt1-dev libssl-dev
python -m easy_install --upgrade pyOpenSSL
pip install elastalert
Dado que cuando implemente está instalación había problemas con la versión 7 de Elasticsearch tuve que instalar elastalert==0.2.0b2, la cual es la versión beta, si ya que consiguieron arreglar todos los problemas en la versión estable instale mediante el comando anterior elastalert
pip install elastalert==0.2.0b2
Creamos el directorio para almacenar las reglas
mkdir -p ~/elastalert/rules
Descargamos la plantilla en https://github.com/Yelp/elastalert/blob/master/config.yaml.example en ~/elastalert/config.yaml
cd ~/elastalert/rules
Debería quedar algo similar a esto: (En mi caso pongo localhost dado que lo estoy instalando dentro de un servidor del cluster de elasticsearch, en caso de instalarlo por separado deberás apuntar a la ip de tu nodo maestro.
rules_folder: /home/username/elastalert/rules
run_every:
minutes: 1
buffer_time:
minutes: 15
es_host: localhost
es_port: 9200
use_ssl: False
writeback_index: elastalert_status
alert_time_limit:
days: 2
Ejecutamos el comando elastalert-create-index el cual nos tiene que devolver algo similar a esto:
Elastic Version: 7.1.0
Reading Elastic 6 index mappings:
Reading index mapping 'es_mappings/6/silence.json'
Reading index mapping 'es_mappings/6/elastalert_status.json'
Reading index mapping 'es_mappings/6/elastalert.json'
Reading index mapping 'es_mappings/6/past_elastalert.json'
Reading index mapping 'es_mappings/6/elastalert_error.json'
New index elastalert_status created
Done!
Nos vamos a theHive: Admin > Users > Add User
Creamos un usuario sin roles y presionamos la opción de Allow Alerts creation
Damos Click a Create API Key y la copiamos
Ahora vamos a crear una regla para probar el funcionamiento, para ello vamos a utilizar rule.id: «5710» que es los intentos fallidos de inicio de sesión mediante SSH
vi ~/elastalert/rules/failed_ssh_login.yaml
es_host: localhost
es_port: 9200
name: Failed password for invalid user
type: frequency
index: wazuh-alerts-3.x-*
num_events: 2
timeframe:
hours: 1
filter:
- term:
rule.id: "5710"
alert: hivealerter
hive_connection:
hive_host: http://ip_thehive
hive_port: 9000
hive_apikey: <Paste API key for elastalert user here>
hive_alert_config:
title: '{rule[name]}'
type: 'external'
source: 'elastalert'
description: '{match[full_log]}'
severity: 2
tags: ['{rule[name]}', '{match[agent][name]}', '{match[predecoder][program_name]}']
tlp: 3
status: 'New'
follow: True
hive_observable_data_mapping:
- ip: "{match[src_ip]}"
Ahora nos vamos a los servidores Logstash para modificar la configuración de 01-wazuh.conf
Debemos cambiar en el filtro de [data][srcip] «@src_ip» por «src_ip», quedando de la siguiente forma
filter {
if [data][srcip] {
mutate {
add_field => [ "src_ip", "%{[data][srcip]}" ]
}
}
Del mismo modo, en el filtro de geoip debemos cambiar «@src_ip» por «src_ip» quedando de la siguiente manera:
filter {
geoip {
source => "src_ip"
target => "GeoLocation"
fields => ["city_name", "country_name", "region_name", "location"]
}
En caso de no funcionar con logstrash, nos vamos a la configuración de filebeat y cambiamos @src_ip por src_ip
- rename:
fields:
- from: "data.srcip"
to: "src_ip"
También debemos descomentar la linea
pipeline: geoip
Una vez cambiado debemos de ir a Kibana: Management > Kibana > Index Patterns, seleccionamos wazuh-alerts y presionamos a actualizar
Ahora si todo a salido bien, debería salir el registro src_ip en wazuh-alerts
Comprobamos la configuración de la alerta creada
elastalert-test-rule ~/elastalert/rules/failed_ssh_login.yaml
Activamos la alerta
elastalert --verbose --config ~/elastalert/config.yaml
Para probar intentamos acceder con un usuario que no exista tres veces por ssh, Si nos dirigimos a Kibana veremos una alerta
Ahora nos debemos de ir a TheHive y comprobar que haya generado una alerta
Una vez probado que funciona correctamente, vamos a generar un servicio para elastalert
vi /etc/systemd/system/elastalert.service
[Unit]
Description=elastalert
After=multi-user.target
[Service]
Type=simple
WorkingDirectory=/home/username/elastalert/
ExecStart=/usr/local/bin/elastalert --debug --config /home/username/elastalert/config.yaml
[Install]
WantedBy=multi-user.target
Iniciamos el servicio
systemctl daemon-reload
systemctl enable elastalert.service
systemctl start elastalert.service
systemctl status elastalert.service
:wq!
Excelente manual aun no lo acabo, pero todo va de maravilla, estaria perfecto que hicieras un tutorial sobre la administración de la plataforma.
EXCELENTE
Muy buen aporte !!!
Me gustaria saber si tenes un modelo para enviar las alertas de un ids al MISP.
Vi en varias comunidades algunos en py, pero al momento de implementar simplemente no funcionan o da errores.