OSSEC – ANALYSE avec SQL et GRAFANA – CONTRE MESURES

OSSEC – ANALYSE avec SQL et GRAFANA – CONTRE MESURES

1 mai 2019 Detection intrusion ossec 0

Vous avez installé OSSEC sur votre infrastructure, le système fonctionne bien, les alertes sont stockées dans une base MariaDB/Mysql. Tous les jours vous voyez les alertes arriver par email, heureusement, leur nombre est limité, cette limite est déterminée par la configuration d’OSSEC.

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
<alerts/>

Avec cette configuration, chaque alerte dont le niveau >= 1 est stocké dans la base Mysql, seules les alertes dont le niveau >= 7 sont envoyées par email. La visualisation des emails ne permettent pas d’évaluer le nombre d’alertes attribuées à une seule et même adresse IP. On sait que OSSEC fonctionne bien mais il serait intéressant d’obtenir quelques statistiques relatives à ces tentatives d’intrusions, et pourquoi pas envisager un système de fédération permettant d’identifier les adresses IP suspectes…

Si vous ne recevez que quelques emails, OSSEC effectue, en arrière plan, un travail considérable.
Après 3 mois d’exposition sur internet, vous serez surpris de voir le nombre d’enregistrements inscrits dans la table “alerts” de la base de données “ossec”. Personnellement, sa taille dépasse le millions d’enregistrements, y compris les alertes générées sur le réseau local.
Pour exploiter ces données, connectez-vous à la base de données, avec “mysql” (console), phpmyadmin, etc… et nous allons analyser quelques points au moyens de requêtes SQL basiques.

Préparation

Le but de ce billet est de travailler sur les alertes provenant d’incidents relevés sur les liaisons Internet. Pour écarter toutes les alertes provenant des réseaux locaux, vous devez déterminer la liste des réseaux locaux auxquels les serveurs sont connectés. Les exemples qui suivent utiliseront les réseaux locaux : 10.40.0.0/24 et 192.168.0.0/24.

ATTENTION

Je limite volontairement l’étendue des analyses à l’internet pour limiter la taille des résultats obtenus, mais n’écartez pas de votre esprit, que les analyses doivent aussi être faites côtés “Réseaux locaux”, et c’est à mon avis, le plus compliqué aujourd’hui. La vie réelle ne ressemble pas à celle du film “Die Hard 4”. Les menaces viennent maintenant plus de l’intérieur que de l’extérieur.

Détection des sources IP les plus fréquentes

Sélection de toutes les sources en provenance d’Internet, affichage de la “source” et du “nombre de fois rencontré” et classé par ordre décroissant sur le “nombre de fois rencontrés”.

SELECT src_ip as a ,count(src_ip) as c FROM alert WHERE ( src_ip <> ‘(null)’ AND src_ip <> ‘::’ AND src_ip <> ‘::1’ AND src_ip <> ‘127.0.0.1’ AND src_ip NOT LIKE ‘10.40.0.%’ AND src_ip NOT LIKE ‘192.168.0.%’ ) GROUP BY src_ip ORDER BY c DESC

La liste peut être très impressionnante. Intéressons-nous aux cas dont le “nombre de fois rencontré” est supérieur à 1000.

SELECT src_ip as a ,count(src_ip) as c FROM alert WHERE ( src_ip <> ‘(null)’ AND src_ip <> ‘::’ AND src_ip <> ‘::1’ AND src_ip <> ‘127.0.0.1’ AND src_ip NOT LIKE ‘10.40.0.%’ AND src_ip NOT LIKE ‘192.168.0.%’ ) GROUP BY src_ip HAVING c > 1000 ORDER BY c DESC

J’obtiens une liste d’adresses avec des nombres “affolants”. Connecté à l’internet, les chiffres deviennent vite démesurés, car ce type d’attaques est orchestré par des robots.

On voit apparaître des adresses du segment chinois “218.92.0.xxx”, on va s’intéresser une des autres adresses. Je vais regarder dans la base quel types d’attaques sont utilisés par ces adresses IP :

SELECT FROM_UNIXTIME(timestamp),level,full_log FROM alert WHERE (src_ip = ‘XXX.XXX.XXX.XXX’) ORDER BY timestamp DESC

Toutes les attaques sont du même type pour cet hôte. A propos de la fréquence, par défaut, OSSEC bloque l’adresse IP pendant 600 secondes à partir d’un “level 6” détecté ( 600 secondes = 10 minutes). La fréquence de l’attaque est supérieure à la fréquence du blocage OSSEC, il est fort probable que le bot s’adapte à la contre mesure.

Contres mesures

La contre mesure principale est gérée par OSSEC et on le voit bien, d’après ses traces, qu’il “fait le boulot”.
Vous pouvez aussi contacter le fournisseur d’accès de cette adresse IP.
Chaque Datacenter dispose d’une adresse email du type “abuse@domainefournisseur”. Vous risquez d’écrire très souvent. Pour trouver l’information concernant l’adresse IP, vous pouvez utilisez la commande whois : whois XXX.XXX.XXX.XXX

inetnum: XXX.XXX.XXX.0 – XXX.XXX.XXX.255
netname: PROVIDER
country: FR
….

remarks: ————————————————
remarks: Abuse notifications to: abuse@PROVIDER
remarks: ———————————————–


Pour traiter le problème définitivement, je bloque définitivement cette adresse IP, en utilisant la même technique que OSSEC : Ajout de l’adresse IP sélectionnée dans le fichier /etc/hosts.deny.
Attention, OSSEC utilise ce ficher dès son démarrage, en créant une copie de l’original, qu’il remet en place, lors de son arrêt.
Si vous modifiez ce fichier avec le processus OSSEC actif, vous perdrez ces modifications à chaque arrêt/redémarrage de OSSEC.
La bonne pratique est :
systemctl stop ossec
# Ajout de l’adresse IP au fichier /etc/hosts.deny
systemctl start ossec

Ajout d’une adresse IP ou d’un segment IP : /etc/hosts.deny

La meilleur solution est de lire le man : man hosts.deny

Pour une seule adresse IP : [nom du démon (process) ou Port ou Wildcard]:[adresse IP] Ex : ALL:192.168.0.1
Pour une liste d’adresses IP : [nom du démon (process) ou Port ou Wildcard]:[adresse IP],[adresse IP], … Ex : ALL:192.168.0.1,192.168.0.2
Pour un segment complet : [nom du démon (process) ou Port ou Wildcard]: [notation CIDR assimilée] Ex : ALL:192.168.0. pour tous les process, et pour le réseau 192.168.0.0/24 (192.168.0.0/255.255.255.0)

Vous pouvez indiquez le Wilcard ALL pour tous les process, sinon indiquez le nom du process de votre choix (ex : in.fingerd ou ALL EXCEPT in.fingerd, ….).

Pour mon cas, j’indique : ALL:XXX.XXX.XXX.XXX
Je préfère la notation “une ip par ligne” plutôt qu’une liste d’adresse, chacun fait comme il souhaite.

Aucun action n’est requise, la modification est prise en compte immédiatement par le Kernel.

GRAFANA et OSSEC

Cette implémentation ne sera possible que si vous avez paramétré OSSEC pour un stockage des alertes dans une base de donnes “MariaDB/Mysql”. L’outil GRAFANA dispose d’un connecteur Mysql, il sera donc possible de le connecter facilement à la base de données “ossec” et commencer à construire un dashboard, selon vos besoins.

Exemple de tableau de bord (Dashboard)

N.B. : Des connaissances sur Grafana et SQL sont nécessaires.

ALLER PLUS LOIN

  • Créer une liste centralisée des Ip à “blacklister” pour les frontaux internet.
  • Créer un bot qui met à jour cette liste et qui installe cette dernières sur tous les serveurs frontaux.

Licence de ce documentCreative Commons(CC BY-NC-ND 4.0)
CETTE DOCUMENTATION EST LIVRÉE “EN L’ÉTAT”, SANS GARANTIE D’AUCUNE SORTE ET DISTRIBUÉE DANS UN BUT ÉDUCATIF EXCLUSIVEMENT. L’AUTEUR, CONTRIBUTEURS DE CETTE DOCUMENTATION OU ©MYTINYDC.COM NE SAURAIENT EN AUCUN CAS ÊTRE TENUS RESPONSABLES DES DOMMAGES DIRECTS OU INDIRECTS POUVANT RÉSULTER DE L’APPLICATION DES PROCÉDURES MISES EN ŒUVRE DANS CETTE DOCUMENTATION, OU DE LA MAUVAISE INTERPRÉTATION DE CE DOCUMENT

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

− 2 = 1

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.