À la fin nous nous sommes rencontrés Pile ELK, de quels produits logiciels il s'agit. Et la première tâche à laquelle un ingénieur est confronté lorsqu'il travaille avec la pile ELK est d'envoyer des journaux pour les stocker dans elasticsearch pour une analyse ultérieure. Cependant, ce ne sont que des paroles en l'air : elasticsearch stocke les journaux sous forme de documents avec certains champs et valeurs, ce qui signifie que l'ingénieur doit utiliser divers outils pour analyser le message envoyé par les systèmes finaux. Cela peut être fait de plusieurs manières : écrivez vous-même un programme qui ajoutera des documents à la base de données à l'aide de l'API, ou utilisez des solutions prêtes à l'emploi. Dans ce cours, nous considérerons la solution Logstash, qui fait partie de la pile ELK. Nous verrons comment envoyer les journaux des systèmes de points de terminaison vers Logstash, puis nous configurerons un fichier de configuration pour analyser et rediriger vers la base de données Elasticsearch. Pour ce faire, nous prenons les journaux du pare-feu Check Point comme système entrant.
Le cours ne couvre pas l'installation de la pile ELK, car il existe un grand nombre d'articles sur ce sujet ; nous considérerons le composant de configuration.
Élaborons un plan d'action pour la configuration de Logstash :
- Vérifier qu'elasticsearch acceptera les journaux (vérifier la fonctionnalité et l'ouverture du port).
- Nous réfléchissons à la manière dont nous pouvons envoyer des événements à Logstash, choisir une méthode et la mettre en œuvre.
- Nous configurons Input dans le fichier de configuration Logstash.
- Nous configurons Output dans le fichier de configuration Logstash en mode débogage afin de comprendre à quoi ressemble le message du journal.
- Configuration du filtre.
- Configuration de la sortie correcte dans ElasticSearch.
- Logstash se lance.
- Vérification des journaux dans Kibana.
Examinons chaque point plus en détail :
Vérifier qu'elasticsearch acceptera les journaux
Pour ce faire, vous pouvez utiliser la commande curl pour vérifier l'accès à Elasticsearch depuis le système sur lequel Logstash est déployé. Si vous avez configuré l'authentification, nous transférons également l'utilisateur/mot de passe via curl, en spécifiant le port 9200 si vous ne l'avez pas modifié. Si vous recevez une réponse similaire à celle ci-dessous, alors tout est en ordre.
[elastic@elasticsearch ~]$ curl -u <<user_name>> : <<password>> -sS -XGET "<<ip_address_elasticsearch>>:9200"
{
"name" : "elastic-1",
"cluster_name" : "project",
"cluster_uuid" : "sQzjTTuCR8q4ZO6DrEis0A",
"version" : {
"number" : "7.4.1",
"build_flavor" : "default",
"build_type" : "rpm",
"build_hash" : "fc0eeb6e2c25915d63d871d344e3d0b45ea0ea1e",
"build_date" : "2019-10-22T17:16:35.176724Z",
"build_snapshot" : false,
"lucene_version" : "8.2.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
[elastic@elasticsearch ~]$
Si la réponse n'est pas reçue, plusieurs types d'erreurs peuvent survenir : le processus elasticsearch n'est pas en cours d'exécution, le mauvais port est spécifié ou le port est bloqué par un pare-feu sur le serveur sur lequel elasticsearch est installé.
Voyons comment envoyer des journaux à Logstash à partir d'un pare-feu de point de contrôle
Depuis le serveur de gestion Check Point, vous pouvez envoyer des journaux à Logstash via syslog à l'aide de l'utilitaire log_exporter, vous pouvez en savoir plus ici , nous ne laisserons ici que la commande qui crée le flux :
cp_log_export ajouter le nom check_point_syslog serveur-cible < > port cible protocole 5555 format TCP mode lecture générique semi-unifié
< > - adresse du serveur sur lequel Logstash s'exécute, port cible 5555 - port auquel nous enverrons les journaux, l'envoi de journaux via TCP peut charger le serveur, donc dans certains cas, il est plus correct d'utiliser udp.
Configuration d'INPUT dans le fichier de configuration Logstash
Par défaut, le fichier de configuration se trouve dans le répertoire /etc/logstash/conf.d/. Le fichier de configuration se compose de 3 parties significatives : INPUT, FILTER, OUTPUT. DANS CONTRIBUTION nous indiquons d'où le système prendra les journaux, dans FILTRE analyser le journal - définir comment diviser le message en champs et valeurs, dans SORTIE nous configurons le flux de sortie - où les journaux analysés seront envoyés.
Tout d'abord, configurons INPUT, considérons certains des types qui peuvent l'être - fichier, tcp et exe.
TCP :
input {
tcp {
port => 5555
host => “10.10.1.205”
type => "checkpoint"
mode => "server"
}
}
mode => "serveur"
Indique que Logstash accepte les connexions.
port => 5555
hôte => « 10.10.1.205 »
Nous acceptons les connexions via l'adresse IP 10.10.1.205 (Logstash), port 5555 - le port doit être autorisé par la politique de pare-feu.
tapez => "point de contrôle"
Nous marquons le document, très pratique si vous avez plusieurs connexions entrantes. Par la suite, pour chaque connexion, vous pouvez écrire votre propre filtre en utilisant la construction logique if.
Fichier:
input {
file {
path => "/var/log/openvas_report/*"
type => "openvas"
start_position => "beginning"
}
}
Description des paramètres :
chemin => "/var/log/openvas_report/*"
Nous indiquons le répertoire dans lequel les fichiers doivent être lus.
tapez => "openvas"
Type d'événement.
start_position => "début"
Lors de la modification d'un fichier, il lit l'intégralité du fichier ; si vous définissez « fin », le système attend que de nouveaux enregistrements apparaissent à la fin du fichier.
Exécutif :
input {
exec {
command => "ls -alh"
interval => 30
}
}
En utilisant cette entrée, une (uniquement !) commande shell est lancée et sa sortie est transformée en un message de journal.
commande => "ls -alh"
La commande dont la sortie nous intéresse.
intervalle => 30
Intervalle d’invocation de la commande en secondes.
Afin de recevoir les logs du pare-feu, nous enregistrons un filtre tcp ou udp, selon la manière dont les journaux sont envoyés à Logstash.
Nous configurons Output dans le fichier de configuration Logstash en mode débogage afin de comprendre à quoi ressemble le message du journal
Après avoir configuré INPUT, nous devons comprendre à quoi ressemblera le message de journal et quelles méthodes doivent être utilisées pour configurer le filtre de journal (analyseur).
Pour ce faire, nous utiliserons un filtre qui affiche le résultat sur la sortie standard afin de visualiser le message d'origine ; le fichier de configuration complet ressemblera actuellement à ceci :
input
{
tcp
{
port => 5555
type => "checkpoint"
mode => "server"
host => “10.10.1.205”
}
}
output
{
if [type] == "checkpoint"
{
stdout { codec=> json }
}
}
Exécutez la commande pour vérifier :
sudo /usr/share/logstash/bin//logstash -f /etc/logstash/conf.d/checkpoint.conf
On voit le résultat, l'image est cliquable :
Si vous le copiez, cela ressemblera à ceci :
action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,0x5,0xfe0a0a0a,0xc0000000}" origin="10.10.10.254" originsicname="CN=ts-spb-cpgw-01,O=cp-spb-mgmt-01.tssolution.local.kncafb" sequencenum="8" time="1576766483" version="5" context_num="1" dst="10.10.10.10" dst_machine_name="[email protected]" layer_name="TSS-Standard Security" layer_name="TSS-Standard Application" layer_uuid="dae7f01c-4c98-4c3a-a643-bfbb8fcf40f0" layer_uuid="dbee3718-cf2f-4de0-8681-529cb75be9a6" match_id="8" match_id="33554431" parent_rule="0" parent_rule="0" rule_action="Accept" rule_action="Accept" rule_name="Implicit Cleanup" rule_uid="6dc2396f-9644-4546-8f32-95d98a3344e6" product="VPN-1 & FireWall-1" proto="17" s_port="37317" service="53" service_id="domain-udp" src="10.10.1.180" ","type":"qqqqq","host":"10.10.10.250","@version":"1","port":50620}{"@timestamp":"2019-12-19T14:50:12.153Z","message":"time="1576766483" action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,
En regardant ces messages, on comprend que les logs ressemblent à : field = value ou key = value, ce qui signifie qu'un filtre appelé kv convient. Afin de choisir le bon filtre pour chaque cas spécifique, il serait judicieux de vous familiariser avec eux dans la documentation technique, ou de demander à un ami.
Configuration du filtre
Lors de la dernière étape nous avons sélectionné kv, la configuration de ce filtre est présentée ci-dessous :
filter {
if [type] == "checkpoint"{
kv {
value_split => "="
allow_duplicate_values => false
}
}
}
Nous sélectionnons le symbole par lequel nous diviserons le champ et la valeur - « = ». Si nous avons des entrées identiques dans le journal, nous enregistrons une seule instance dans la base de données, sinon vous vous retrouverez avec un tableau de valeurs identiques, c'est-à-dire que si nous avons le message "foo = some foo=some", nous écrivons uniquement foo = certains.
Configurer la sortie correcte dans ElasticSearch
Une fois le filtre configuré, vous pouvez télécharger les journaux dans la base de données elasticsearch:
output
{
if [type] == "checkpoint"
{
elasticsearch
{
hosts => ["10.10.1.200:9200"]
index => "checkpoint-%{+YYYY.MM.dd}"
user => "tssolution"
password => "cool"
}
}
}
Si le document est signé avec le type point de contrôle, nous enregistrons l'événement dans la base de données elasticsearch, qui accepte les connexions sur 10.10.1.200 sur le port 9200 par défaut. Chaque document est enregistré dans un index spécifique, dans ce cas nous enregistrons dans l'index « point de contrôle- » + date et heure actuelle. Chaque index peut avoir un ensemble spécifique de champs ou est créé automatiquement lorsqu'un nouveau champ apparaît dans un message ; les paramètres des champs et leur type peuvent être visualisés dans les mappages.
Si vous avez configuré l'authentification (nous y reviendrons plus tard), les informations d'identification pour écrire dans un index spécifique doivent être spécifiées, dans cet exemple il s'agit de « tssolution » avec le mot de passe « cool ». Vous pouvez différencier les droits des utilisateurs pour écrire des journaux uniquement dans un index spécifique et pas plus.
Lancez Logstash.
Fichier de configuration Logstash :
input
{
tcp
{
port => 5555
type => "checkpoint"
mode => "server"
host => “10.10.1.205”
}
}
filter {
if [type] == "checkpoint"{
kv {
value_split => "="
allow_duplicate_values => false
}
}
}
output
{
if [type] == "checkpoint"
{
elasticsearch
{
hosts => ["10.10.1.200:9200"]
index => "checkpoint-%{+YYYY.MM.dd}"
user => "tssolution"
password => "cool"
}
}
}
Nous vérifions l'exactitude du fichier de configuration :
/usr/share/logstash/bin//logstash -f checkpoint.conf
Démarrez le processus Logstash :
sudo systemctl démarrer logstash
On vérifie que le processus a démarré :
sudo systemctl statut logstash
Vérifions si la socket est active :
netstat -nat |grep 5555
Vérification des journaux dans Kibana.
Une fois que tout est exécuté, allez sur Kibana - Discover, assurez-vous que tout est correctement configuré, l'image est cliquable !
Tous les logs sont en place et nous pouvons voir tous les champs et leurs valeurs !
Conclusion
Nous avons examiné comment écrire un fichier de configuration Logstash et avons obtenu un analyseur de tous les champs et valeurs. Nous pouvons désormais travailler sur la recherche et le traçage de champs spécifiques. Ensuite, dans le cours, nous examinerons la visualisation dans Kibana et créerons un tableau de bord simple. Il convient de mentionner que le fichier de configuration Logstash doit être constamment mis à jour dans certaines situations, par exemple lorsque nous souhaitons remplacer la valeur d'un champ d'un nombre par un mot. Dans les articles suivants, nous le ferons constamment.
Alors restez à l'écoute, , , ), .
Source: habr.com