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.
<code>
<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
<alerts/>
</code>
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”.
Après 6 mois d’utilisation, sa taille dépasse les 3 millions d’enregistrements, non 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 à celle de l’internet, mais n’écartez pas de votre esprit, que les analyses doivent aussi être faites côtés “Réseaux locaux”. La vie réelle ne ressemble pas à celle du film “Die Hard 4”. Les menaces viennent 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, du nombre de fois rencontrées et classées par ordre décroissant sur le nombre de fois rencontrées (sources).
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ées” 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 quels 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
Remarque importante sur cette contre-mesure
J’utilise dans cette démonstration le principe “hosts.deny”. Sachez que ce mécanisme fonctionne uniquement sur les services supportant la librairie “libwrap.a” (TCP Wrappers). Si le service à protéger n’intègre pas cette librairie, la contre-mesure sera inefficace. Pour savoir sur le service supporte cette librairie, utilisez la commande “ldd” appliquée à l’exécutable du service. Exemple pour ssh :
ldd /sbin/sshd | grep libwrap
donne :
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f1fea580000)
Essayez avec “apache2”:
ldd /usr/sbin/apache2 | grep libwrap
aucun résultat.
Par conséquent, le mécanisme TCP Wrappers n’a aucune action sur le service “apache2”, vous devrez utiliser le Firewall.
source : https://www.thegeekdiary.com/understanding-tcp-wrappers-in-linux/
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 document : Creative 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.