Analyse de logs Bind 🔗

Posted by MĂ©dĂ©ric Ribreux 🗓 In projects/ELK/

Introduction

Cette partie a pour objet de trouver le moyen d'obtenir le plus d'informations possible des logs issus de Bind. Ce serveur DNS peut ĂȘtre verbeux lorsqu'on a pris soin de configurer la partie des logs. On peut ainsi tracer toute demande de requĂȘte DNS sur le serveur et analyser en profondeur ces demandes.

Contenu des logs

Avant de commencer, étudtions un peu ce qu'on peut récupérer dans un log Bind (requests.log):

26-Aug-2015 21:41:58.579 info: client 192.168.0.15#50651 (sourceforge.net): query: sourceforge.net IN A + (192.168.0.4)

Voici ce qu'on peut récupérer dans l'ordre d'apparition:

Au final, cela fait quelques champs à gérer:

Pour ma part, je n'ai qu'un seul DNS donc rĂ©cupĂ©rer son adresse n'a pas trop d'intĂ©rĂȘt.

Capturer l'information du log

Logstash vient sans filtre tout prĂȘt. Cette fois, il va falloir expĂ©rimenter et pour cela, il nous faut dĂ©finir nos propres motifs grok.

Le plus simple consiste à copier le fichier ./vendor/bundle/jruby/1.9/gems/logstash-patterns-core-0.3.0/patterns/grok-patterns dans un répertoire ./patterns sous le nom que vous voulez. Ensuite, dans votre filtre grok, il faudra indiquer qu'on souhaite utiliser ce répertoire comme répertoire de motifs. Cela est possible grùce à la directive patterns_dir.

Etudions notre filtre grok...

D'abord, il nous faut récupérer la date et l'heure pour faire un timestamp. Si on regarde les filtres grok du fichier grok-patterns, on se rend compte qu'aucun ne correspond. Il faut l'exprimer en essayant d'utiliser les motifs déjà présent. Pour ma part, j'ai trouvé la forme suivante:

BINDTIMESTAMP %{MONTHDAY}-%{MONTH}-%{YEAR} %{TIME}

Rien de bien compliqué mais nous voilà équipé.

Ensuite, il n'y a rien pour les requĂȘtes DNS. Ici, nous allons crĂ©er un motif simple:

DNSQUERY A|AAAA|MX|SRV|TXT

Pour le reste, on va pouvoir se débrouiller avec les motifs grok livrés avec Logstash. Donc, ajoutez les deux lignes mentionnées plus haut dans votre fichier ./patterns/extra.

Pour rĂ©cupĂ©rer l'IP du client, il suffit d'utiliser le motif IP. Pour rĂ©cupĂ©rer le domaine requĂȘtĂ©, le motif HOST fait l'affaire.

L'ensemble donne le filtre grok suivant:

"%{BINDT:timestamp} info: client %{IP:ipaddress}#[0-9]{0,5} \(%{HOSTNAME}\): query: %{HOST:domain} IN %{DNSQUERY:query_type}"

Fichier de configuration de logstash

Voici les entrées et le filtre pour Logstash qui correspond à la configuration cible exposée ci-dessus. Nous allons ajouter un type nommé bind pour identifier les logs de bind des autres.

file {
  path => "/home/medspx/projects/ELK/data/bind/request*.log"
  start_position => beginning
  type => "bind"
}

filter {
  # Filtre pour les logs Bind
  if [type] == "bind" {
    # L'intégralité des données du log est récupérée via le motif étudié plus haut
    grok {
        patterns_dir => "./patterns"
        match => { "message" => "%{BINDT:timestamp} info: client %{IP:ipaddress}#[0-9]{5} \(%{HOSTNAME}\): query: %{HOST:domain} IN %{DNSQUERY:query_type}" }
    }
    date {
      match => [ "timestamp", "dd-MMM-YYYY HH:mm:ss.SSS" ]
    }
  }
}

Notez le timestamp pour récupérer la date de l'évÚnement. La forme dd-MMM-YYYY HH:mm:ss.SSS permet de récupérer l'information à la milliseconde.

Reporting

Introduction

Grùce au filtre logstash précédent, nous disposons de quelques variables que nous allons exploiter. Voici ce que j'ai imaginé

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

MĂ©trique: Nombre de requĂȘtes selon le temps

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

MĂ©trique: Les 10 domaines les plus requĂȘtĂ©s

Autre métrique assez simple qui travaille sur le champ domain que nous avons défini dans le filtre Logstash.

MĂ©trique: Les 10 clients qui font le plus de requĂȘtes

Autre métrique assez simple qui travaille sur le champ ipaddress que nous avons défini dans le filtre Logstash.

MĂ©trique: Quels sont les 10 domaines les plus requĂȘtĂ©s sur les 10 clients principaux

Pour cette mesure, nous allons utiliser une table et les deux champs visualisés précédemment.

MĂ©trique: Ratio requĂȘtes DNS A vs AAAA

Ici, nous allons utiliser des filtres...

Et voilĂ  ! Rien de bien complexe...

MĂ©trique: Ratio requĂȘtes des principaux rĂ©seaux sociaux par rapport Ă  l'ensemble des requĂȘtes

Voici la recette Ă  appliquer:

Conclusion

On peut bien entendu ajouter d'autres mesures. En effet, les logs Bind sont une source prĂ©cieuse pour savoir ce que vos client font sur votre rĂ©seau local. Quels sont les domaines les plus visitĂ©s, quels sont les domaines non valides, quels sont les domaines locaux les plus requĂȘtĂ©s, etc.

Avec un peu de réflexion et de fabrication de motifs, on peut tout mettre dans Elasticsearch et faire de beaux diagrammes avec Kibana, comme d'habitude. Attention, les logs Bind sont souvent trÚs volumineux. Ils occasionneront sans doute une grosse charge sur l'instance Logstash qui sera chargée de les traiter. Bien entendu, votre instance Elasticsearch consommera sans doute beaucoup d'espace disque. Mais intégrer les logs Bind est souvent payant pour observer le comportement de vos clients, le jeu en vaut souvent la chandelle. A vous de voir si vous voulez exploiter cette manne !