Monitoring avec ELK – Logstash!

Bonjour à toi lecteur! (Si tant est que quelqu’un lise cette page…)

On a vu comment mettre en place la stack ELK pour faire nos tests, maintenant on va se lancer dans le paramétrage de logstash afin qu’on puisse lui balancer des logs au format syslog, depuis un routeur IpFire via le port UDP 514.

Je me suis aidé de ce tuto DigitalOcean.

Dans un premier temps on va devoir créer un « écouteur » (j’ai pas trouvé de mot plus joli…) pour logstash.

Toutes les confs se gèrent dans le dossier /etc/logstash/conf.d/ chaque fichier .conf de ce dossier sera pris en compte par l’application.

On va créer un fichier 0-inputs.conf et on va lui définir ceci :

#udp syslog udp 514

input {
  udp {
    type => "ipfire-syslog"
    port => 514
  }
}

On lui dit de créér un écouteur UDP sur le port 514 et d’ajouter le tag ipfire-syslog à tout ce qui rentre par là!

On redémarre le service logstash (service logstash restart) et…. Fume!

Java n’a pas le droit d’écouter sur les ports entre 0 et 1023 pour des raisons de sécurités, c’est un « vrai » problème car le syslog du routeur que je veux superviser n’est pas configurable. (ou alors je n’ai pas trouvé comment faire…)

On va donc donner le droit à Java d’écouter sur les ports réservés au système en executant ces commandes, voir le github de logstash pour plus d’info :

setcap cap_net_bind_service=+epi /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 

On vérifie avec un petit netstat -au que le port est bien en écoute :

root@elk:/etc/logstash/conf.d# netstat -au
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat      
udp        0      0 *:54328                 *:*                                
udp        0      0 *:syslog                *:*                                

Youpi! ça marche.

On va maintenant créer un fichier 9-outputs.conf au même endroit que le précédent afin de definir ou les logs doivent être transportés après traitement, ici on forward ça direct à Elasticsearch sur le même host.

output {
  elasticsearch { host => localhost }
  stdout { codec => rubydebug }
}

On redémarre Logstash, et normalement maintenant on devrait voir arriver nos logs au travers Kibana, j’ai cliqué sur le prebuilt dashboard.

 

cap1
 

En cliquant sur le détails des logs,  on voit bien que le champ « _type » est bien renseigné comme paramétré dans le fichier de conf de logstash.

log
 

Mais on comprends vite aussi en regardant le champ « message » que c’est inexploitable en l’état, il va falloir les découper et faire rentrer les différentes infos dans différentes cases…

C’est la que notre ami logstash va nous montrer son utilité!

Le Parsing! grand sujet… que je ne maitrise absolument pas, en gros, on va essayer de décrire le format de notre log via des patterns pré-éxistants (Grok) et des automatismes (kv) afin de séparer nos logs en différentes parties.

Je cherche a parser les logs du firewall (notamment les packets rejetés) dont l’id est <4>, j’ai donc créé un nouveau fichier dans /etc/logstash/conf.d/ appelé 1-ipfire.conf avec le contenu suivant :

filter {
# On filtre le log par type
  if [type]  == "ipfire-syslog" {
        # On cherche la chaine de caracteres "<4>" dans le log
        if "<4>" in [message] {
                # On applique le filtre Grok souhaité
                grok {
                match => { "message" => "<%{DATA:event_number}>%{WORD:source}: %{DATA:action} " }
                }
                # On utilise le plugin KV pour decouper automatiquement le reste du log
                kv {}
                #On ajoute le tag Firewall
                mutate {
                add_tag => "Firewall"
                }
        }
}
}

Je vous invite grandement à tester ce service en ligne le « Grok Debugger », ça permet de construire dynamiquement les expression qui conviennent pour décrire ses logs.

Un petit service logstash restart pour charger les modifications, et retour sur kibana, on peut maintenant voir le log découpé en plusieurs catégories !

log-2
 

On peut maintenant jouer avec kibana, en affichant différents types de graphiques ou informations en fonction des requêtes faites sur le contenu.

kibana
 

C’est pas le dashboard de la Nasa non plus, je découvre le truc… Mais on peu aller loin!

Prochaine étape, monitorer nginx, ajouter un filtrage geoip pour afficher les connexions ouvertes sur une carte, etc!

1 commentaire

  1. hey ! 🙂
    très bon tuto !! 😉 juste un point à éclaircir

    Dans ton grok tu ne définit que 3 choses alors que ton log (image en-dessous) est découpé en plein de catégorie différente, comment cela ce fait ?
    as tu rajouté des expressions autres si oui tu peux me donner un autre exemple
    grok {
    match => { « message » => « %{WORD:source}: %{DATA:action}  » }
    }
    cordialement,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.