Maîtriser l’alerte en temps réel avec ElastAlert2: détection des attaques DOS à partir de journaux WAF

Introduction

ElastAlert 2 est un cadre simple pour l’alerte sur les anomalies, les pointes et d’autres modèles d’intérêt pour les données d’Elasticsearch et OpenSearch.

Elastalert 2 est un outil pour surveiller les données en temps réel dans Elasticsearch et alerte sur les modèles de correspondance.

ElastAlert accepte ce type d’alerte:

1. E-mail
2. AWS SES (Amazon Simple Email Service)
3. AWS SNS (Amazon Simple Notification Service)
4. Commande de chat
5. Médecin de données
6. Gooche
7. Jira Slack
8. Télégramme

Il s’agit d’un puissant outil de surveillance, mais il exige des efforts égaux pour réaliser son plein potentiel.

Cas d’utilisation: détection d’attaque DOS en temps réel sur les journaux WAF avec elastalert2

Dans un projet récent, j’ai utilisé Elastalert2 pour surveiller et détecter les attaques de déni de service (DOS) en surveillant les données WAF stockées dans Elasticsearch. Le but était d’envoyer des alertes par e-mail en temps quasi réel lorsque des modèles de trafic suspects indiquant une assaut DOS ont été observés.

Défi

Bien qu’ElastAlert2 soit un cadre efficace pour la détection et l’alerte d’anomalies sur les données Elasticsearch / OpenSesearch, le processus de configuration pourrait être difficile. La documentation est minime et les configurations nécessitent une attention particulière aux détails, en particulier lors de l’interaction avec les pipelines personnalisés et les notifications par e-mail.

Solution

Voici comment j’ai structuré la solution:

1. Mécanisme d’alerte
Le type d’alerte a été défini sur Email (SMTP). Lorsque la condition d’alerte est remplie (par exemple, un modèle DOS est découvert dans les journaux), un e-mail est automatiquement envoyé à l’équipe de réponse aux incidents avec des informations complètes.

2. Type de règle: fréquence.
A développé une règle de fréquence pour détecter au moins un élément de journal lié à DOS dans un délai de 60 minutes. La règle a utilisé des filtres génériques pour capturer des variations telles que DOS * et Behavioral * dans la colonne DOS_ATTACK_NAME.

3. Pipeline pour analyser les journaux JSON imbriqués
Étant donné que les données de journal essentiels ont été imbriquées dans le champ _Source et stockées en JSON brutes dans Event.original, j’ai construit un pipeline d’ingestion personnalisé dans Elasticsearch pour convertir le JSON en champs structurés. Cela a permis à Elastalert2 de visualiser et d’évaluer le matériel de journal réel.

4. Tester avant le déploiement.
Avant de définir l’alerte en tant que service, j’ai utilisé la règle ElastAlert-Test pour évaluer la logique de configuration et de règle, ce qui m’a aidé à identifier les fautes de frappe dans la syntaxe.

5. Intégration de service.
Enfin, configurez Elastalert2 en tant que service SystemD, garantissant qu’il s’exécute continuellement en arrière-plan et redémarre automatiquement lors du redémarrage.

Principaux à retenir

Elastalert2 est idéal pour l’alerte personnalisée mais nécessite une courbe d’installation abrupte. L’analyse JSON via des pipelines Elasticsearch est essentiel lorsque les journaux sont imbriqués. Validez toujours vos règles avant le déploiement de la production à l’aide de la règle ElastAlert-Test-Rule

Condition préalable

sudo yum groupinstall "Development Tools"

sudo yum install libffi-devel

sudo yum install python3-devel

Veuillez noter que les commandes fournies sont uniquement pour les systèmes Linux basés sur Red Hat. Voici les commandes pour les systèmes Linux basés sur Ubuntu:

sudo apt-get install build-essential

sudo apt-get install libffi-dev

sudo apt-get install python3-dev

• Installation d’Elastalert2:

git clone https://github.com/jertel/elastalert2.git

python3 setup.py install

elastalert-create-index
New index name (Default elastalert_status)
Name of existing index to copy (Default None)
New index elastalert_status created
Done!

Configuration de la configuration ElastAlert2:

Elastalert comprend de nombreux fichiers de configuration; C’est à vous de décider si vous les incluez tous dans un seul fichier ou séparez les fichiers de configuration en fonction de leur nature. Par exemple, ici, je sépare mon fichier de configuration de deux manières:

1. Configuration principale
2. Configuration des règles

Configuration principale:

Chemin: / Root / ElastAlert2 / Exemples

# This is the folder that contains the rule yaml files

# This can also be a list of directories

# Any .yaml file will be loaded as a rule

rules_folder: /root/elastalert2/examples/rules

# How often ElastAlert will query Elasticsearch

# The unit can be anything from weeks to seconds

run_every:

minutes: 2

# ElastAlert will buffer results from the most recent

# period of time, in case some log sources are not in real time

buffer_time:

minutes: 15

# The Elasticsearch hostname for metadata writeback

# Note that every rule can have its own Elasticsearch host

es_host: <es_host_ip>

# The Elasticsearch port

es_port: 9200

# The AWS profile to use. Use this if you are using an AWS CLI profile.

# See http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html

# for details

#profile: test

# Optional URL prefix for Elasticsearch

#es_url_prefix: elasticsearch

# Optional prefix for statsd metrics

#statsd_instance_tag: elastalert

# Optional statsd host

#statsd_host: dogstatsd

# Connect with TLS to Elasticsearch

#use_ssl: True

# Verify TLS certificates

#verify_certs: True

# Show TLS or certificate related warnings

#ssl_show_warn: True

# GET request with body is the default option for Elasticsearch.

# If it fails for some reason, you can pass 'GET', 'POST' or 'source'.

# See https://elasticsearch-py.readthedocs.io/en/master/connection.html?highlight=send_get_body_as#transport

# for details

es_send_get_body_as: GET

# Option basic-auth username and password for Elasticsearch

#es_username: someusername

#es_password: somepassword

# Use SSL authentication with client certificates client_cert must be

# a pem file containing both cert and key for client

#ca_certs: /path/to/cacert.pem

#client_cert: /path/to/client_cert.pem

#client_key: /path/to/client_key.key

# The index on es_host which is used for metadata storage

# This can be a unmapped index, but it is recommended that you run

# elastalert-create-index to set a mapping

writeback_index: elastalert_status

# If an alert fails for some reason, ElastAlert will retry

# sending the alert until this time period has elapsed

alert_time_limit:

seconds: 10

_source_enabled: true

logging:

version: 1

formatters:

simple:

format: '%(asctime)s %(levelname)s %(message)s'

handlers:

console:

class: logging.StreamHandler

formatter: simple

level: DEBUG

file:

class: logging.FileHandler

formatter: simple

level: DEBUG

filename: /var/log/elastalert.log  # Adjust the path as needed

root:

level: DEBUG

handlers: [console, file]

smtp_auth_file: /root/elastalert2/examples/smtp_auth_file.yaml

# Alerting (Email)

smtp_host: <smtp_host_address>

smtp_port: <smtp_port>

#smtp_ssl: false

#verify_certs: false

J’utilise la configuration SMTP pour envoyer des notifications par e-mail.

smtp_auth_file Ce fichier comprend le nom d’utilisateur et le mot de passe du serveur SMTP. _Source_enabled Cette variable est vitale, alors assurez-vous de l’inclure dans vos paramètres.

règles_folder Si vous regardez cela, je fais référence à la configuration de mes règles, qui utilise cette variable

En savoir plus sur les autres paramètres du lien ci-dessous. Toutes les variables jouent un rôle crucial dans le test de votre règle. Elastallert détecte rarement des erreurs ou des variables manquantes, il est donc important de y prêter attention.

Tester votre règle

Cependant, il y a un bonus: vous pouvez tester votre configuration et règle avant d’activer votre service ElastAlert, et s’il y a un problème d’exception ou de syntaxe, vous le remarquerez immédiatement.

elastalert-test-rule my_rules/rule1.yaml configuration/config.yaml

Configuration de la règle:

Chemin: / root / elastalert2 / exemples / règles

# Name of the rule

name: "DOS Attack Detection"

# Type of alert rule

type: frequency

# The Elasticsearch index to search

index: big_ip-waf-logs-*

# The filter to match DOS attack logs

filter:

- bool:

should:

- wildcard:

dos_attack_name: "DOS*"

- wildcard:

dos_attack_name: "Behavioral*"

# The timeframe to search for the keyword

timeframe:

minutes: 60

# Alert if at least 1 event is found

num_events: 1

# Use local time for alerts

use_local_time: false

# SMTP authentication file

smtp_auth_file: /root/elastalert2/examples/smtp_auth_file.yaml

# Alert actions

alert:

- email

# Email alert settings

from_addr: "cloudapm@tothenew.com"

email:

- "chetan.singh1@tothenew.com"

# Additional alert details to include in the alert message

alert_subject: "DOS Attack Detected"

alert_text: |

DEVICE TYPE : ELK

APPLICATION NAME : {0}

ACTION : {1}

DOS ATTACK ID : {2}

HOST NAME : {3}

CONTEXT NAME : {4}

ATTACK IP ADDRESS : {5}

DATE : {6}

ITEM NAME : {7}

VALUE : {8}

SEVERITY : Exception

GROUP : L2 Wintel

alert_text_args: ["_index", "action", "dos_attack_id", "hostname", "context_name", "source_ip", "@timestamp", "dos_attack_name", "dos_attack_tps"]

alert_text_type: alert_text_only

alert_missing_value: "NOT FOUND"

# Disable the inclusion of the full event

#include: []

# Define how often this rule can trigger

#realert:

#  minutes: 1

# Aggregation period

#aggregation:

#  minutes: 5

J’utilise la fréquence comme type de règle dans cette configuration, et je recherche des attaques DOS dans mon index Elasticsearch, ou plus spécifiquement, dans les journaux WAF.

La règle et la configuration fonctionnaient correctement; Cependant, une étape a échoué. Des idées?

Le défi _Source Block

Je n’ai pas pu extraire les valeurs d’Elasticsearch car la valeur que nous avons reçue dans l’indice Elasticsearch était contenue dans le _source bloc.

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html

Si vous regardez la documentation officielle du bloc _Source, vous remarquerez qu’il n’est pas consultable; Au lieu de cela, vous pouvez le voir à Kibana Discover.

Pour résoudre ce problème, j’ai activé le _Source_enabled variable et créé un séparé pipeline Pour analyser l’événement original de l’index.

PUT _ingest/pipeline/parse_json

{

"description": "Parse JSON string in event.original field",

"processors": [

{

"json": {

"field": "event.original",

"target_field": "parsed_event"

}

}

]

}

En utilisant cela, j’ai pu extraire des valeurs de l’indice Elasticsearch à l’aide de la configuration ElastAlert.

Running Elastallert comme service

Pour lancer Elastalert en tant que service, créez le fichier suivant: /etc/Systemd/System/elastalert.service.

Et il comprend:

[Unit]

Description=elastalert

After=multi-user.target

[Service]

Type=simple

User=root

Group=root

WorkingDirectory=/root/elastalert2/

ExecStart=/usr/bin/python3 -m elastalert.elastalert --verbose --config /root/elastalert2/examples/config.yaml --rule /root/elastalert2/examples/rules/example_frequency.yaml

StandardOutput=syslog

StandardError=syslog

KillSignal=SIGKILL

[Install]

WantedBy=multi-user.target

Réflexions finales

La configuration d’Elastalert2 peut être intimidante au début en raison de son manque de documentation et de complexité de configuration. Cependant, si vous comprenez sa structure et ses bizarreries – en particulier celles impliquant le champ _Source – cela devient un outil d’alerte extrêmement utile.

En décomposant les configurations en pièces gérables, en testant soigneusement les règles et en tirant parti des outils comme ingérer des pipelines, vous pouvez transformer Elastalert2 en un allié puissant pour une surveillance proactive.

Si vous travaillez avec Elasticsearch et avez besoin d’alerte fiable et configurable, ElastAlert2 vaut bien l’effort de configuration.

Références

https://elastalert2.readthedocs.io/en/latest/ruletypes.html

https://github.com/guertel/elastalert2/tree/master/examples/rules

https://elastalert2.readthedocs.io/_/downloads/en/latest/pdf/