Analyse de logs DHCP🔗

Cette partie a pour objet de trouver le moyen d'obtenir le plus d'info possible des logs issus du serveur DHCP isc-dhcp-server. Ce dernier s'installe assez facilement et permet de gérer l'affectation des adresses IP.

Voici les éléments qu'on cherche à analyser:

• Quels sont les matériels qui se sont connectés les x derniers jours (adresse MAC) ? La réponse à cette question permettra d'identifier plus facilement les matériels nouveaux ou ceux qui ne sont pas désirés.
• Combien de requêtes DHCP par jour et de quel type ?
• Quels sont les types de requêtes DHCP

Voici le contenu d'un log DHCP:

Aug 29 23:59:09 medspx dhcpd: DHCPREQUEST for 192.168.0.22 from 74:29:af:2f:80:fb via eth0

A partir de ces logs, on peut extraire les métriques suivantes:

• dhcp_timestamp: l'heure et la date de l'évènement. Indispensable si on veut garder trace du moment où l'évènement est arrivé.
• dhcp_mac_address: certaines opérations DHCP récupère l'adresse MAC des équipements qui ont demandé une adresse IP. Si on souhaite savoir quel matériel se connecte sur le réseau par DHCP, cette source de données semble indispensable.
• dhcp_src_ip: l'adresse IP attribuée à l'équipement.
• dhcp_action: l'operation DHCP. Plusieurs opérations sont possibles (DHCPREQUEST, DHCPACK, DHCPDISCOVER, etc.). Il paraît important de voir si un ou plusieurs équipements réalisent trop d'actions particulières pour étudier un comportement pouvant poser problème (c'était le cas des équipements sous Android 4.1 par exemple).

Avec ces métriques, on doit pouvoir réaliser des statistiques intéressantes.

Voici un exemple de filtre logstash qui capturera les différentes variables évoquées ci-dessus.

input {
  file {
      path => "/home/medspx/projects/ELK/test/datasource/dhcpd/dhcpd.log"
      start_position => beginning
      type => "dhcpd"
  }
}

filter {
  if [type] == "dhcp" {
    grok {
      match => [ "message" , "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" ]
    }
    date {
      locale => "en"
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
    if [syslog_message] =~ /^DHCPACK|^DHCPREQUEST|^DHCPOFFER|^DHCPNAK|^DHCPRELEASE/ {
      grok {
        match => [ "syslog_message", "(?<dhcp_action>.*) (of|on|for|to) %{IP:src_ip}.* (from|to) %{MAC:mac_address}.* via (?<iface>.*)" ]
      }
    }
    if [syslog_message] =~ /^DHCPDISCOVER/ {
      grok {
        match => [ "syslog_message", "(?<dhcp_action>.*) from %{MAC:mac_address}.* via (?<iface>.*)" ]
      }
    }
    if [syslog_message] =~ /^DHCPINFORM/ {
      grok {
        match => [ "syslog_message", "(?<dhcp_action>.*) from %{IP:src_ip}.* via (?<iface>.*)" ]
      }
    }
  }
}

Grâce au filtre logstash précédent, nous disposons de quelques variables. Que faire avec ? Voici ce que j'ai imaginé:

• Visualiser les demandes DHCP en fonction du temps.
• Lister les adresses MAC qui font des demandes DHCP en les classant par nombre de requêtes.
• Lister les adresses IP les plus attribuées.
• Quelle est la répartition des types de requêtes DHCP.
• Lister les adresses MAC qui font l'objet d'un rejet de la part du serveur.

Comme d'habitude, n'oubliez pas de rafraîchir vos champs (Settings → Logstash-* → bouton Refresh).

Ce métrique est très simple. Voici la recette pour le constituer:

• Filtre: type:dhcpd
• Visualize: Aera chart.
• X-Axis
• Aggregation: Date Histogram
• Field: @timestamp
• Interval: Auto

Cette fois, nous allons utiliser une simple table.

• Filtre: type:dhcpd
• Visualize: Data Table.
• Buckets: split rows.
• Aggregation: Terms
• Field: mac_address.raw
• Order:Top, Size: 100.
• Order by: metric: Count
• Options: Per page : 100.

Ici aussi, nous allons utiliser une simple table.

• Filtre: type:dhcpd
• Visualize: Data Table.
• Buckets: split rows.
• Aggregation: Terms
• Field: src_ip.raw
• Order:Top, Size: 100.
• Order by: metric: Count
• Options: Per page : 100.

Pour ce cas simple, un simple camembert fait l'affaire.

• Filtre: type:bind
• Visualize: New Pie Chart.
• Buckets: split slices.
• Aggregation: Terms
• Field: dhcp_action.raw
• Order: Top
• Size: 10
• Order by: Metric: Count

Ici, il faut filtrer les données selon le contenu du message syslog. En effet, voici un log qui précise un rejet:

Aug 30 13:09:51 medspx dhcpd: DHCPDISCOVER from 00:07:cb:c0:ee:22 via eth0: network 192.168.0.0/24: no free leases

Nous allons utiliser une table (normalement, le nombre de rejet doit être faible):

• Filtre: type:dhcpd AND syslog_message:no free leases
• Visualize: Data Table.
• Buckets: split rows.
• Aggregation: Terms
• Field: mac_address.raw
• Order:Top, Size: 100.
• Order by: metric: Count
• Add Sub-Bucket.
• Split Rows.
• Sub-Aggregation: Terms
• Field: @timestamp
• Order:Top, Size: 100.
• Order by: metric: Count
• Options: Per page : 100.

Voilà, avec ces mesures, on peut mieux observer ce qui se passe pour le DHCP sur le réseau local. On peut identifier les machines qui demandent des baux à répétition assez facilement et modifier les paramètres du client DHCP pour faire baisser le nombre de requêtes (durée du bail par exemple). On peut également voir quelles sont les adresse MAX qui font des demandes et voir s'il n'y a pas des machines non autorisées qui tentent de rejoindre le réseau local IP.

Cette nouvelle source de données vous permettra de continuer à réduire la charge sur votre réseau local et sur le service DHCP.

On peut aller plus loin en tentant d'écrire un filtre logstash qui traduirait les adresses MAC en nom de machines ou en utilisant le filtre translate pour le faire (pas vraiment dynamique mais mieux que rien).