Une étude des bruteforce SSH

Magazine
Marque
MISC
Numéro
76
|
Mois de parution
novembre 2014
|
Domaines


Résumé
Bien que les attaques en bruteforce des SSH fassent partie du bruit blanc du trafic réseau des systèmes connectés, leur étude révèle des profils d'attaquants à l'hétérogénéité intrigante. Leur analyse approfondie grâce à un pot de miel dédié révèle des informations intéressantes sur les agresseurs.

Body

1. Qu'est-ce que c'est ?

Les attaques dites « bruteforce SSH » sont des tentatives de connexions SSH effectuant une succession d'essais pour découvrir un couple utilisateur/mot de passe valide afin de prendre le contrôle de la machine. Il s'agit d'une attaque très répandue et toute machine exposée sur Internet se verra attaquer plusieurs fois par jour.

La fréquence de ces attaques a entraîné l'apparition de diverses méthodes de protection telle que l'utilisation d'un port non standard pour le serveur SSH. Une autre méthode très répandue est l'utilisation d'outils comme Fail2ban [FAIL2BAN] qui analyse les journaux SSH pour trouver les adresses IP responsables de trop nombreux échecs de connexions et modifie la configuration du pare-feu pour bloquer les tentatives ultérieures.

2. Collecte des informations

2.1 Présentation du point de collecte

Cet article présente l’analyse de données collectées sur un ADSL résidentiel français dont l'adresse IPv4 n'est associable à aucun service public. Il s'agit donc d'une adresse anonyme perdue au milieu des 2^32 autres. Des redirections de ports sont utilisées sur le modem routeur pour envoyer le trafic de certains ports vers la machine cible.

2.2 Journaux systèmes

Les premières sources d'information pour récupérer des données sur les bruteforce SSH sont bien entendu les journaux syslog et en particulier ceux générés par le démon SSH :

Aug 24 19:55:10 tiger2 sshd[2525]: Failed password for miscmag from 1.2.3.4 port 48459 ssh2

Ces journaux permettent de récupérer le nom d’utilisateur, l'adresse IP et le port utilisés pour la tentative de connexion. Si cela fournit déjà quelques informations intéressantes, il manque cependant des informations de bas niveaux (niveau TCP) et de haut niveau (niveau applicatif). Il est possible d'obtenir plus de détails dans les journaux en en modifiant le niveau de détail des journaux SSH, mais le côté intrusif de la démarche n'est pas très satisfaisant et elle ne permet pas d'obtenir les informations pour un réseau complet.

2.3 Outils d'analyse réseaux

L'IDPS Suricata [Suricata] présenté dans MISC n°66 est une sonde réseau de détection d'intrusion open source. Elle propose les fonctionnalités d'un IDS basé sur des signatures combiné à des fonctions de surveillance réseau orienté sécurité (Network Security Monitoring) qui ont été renforcées avec la version 2.0 parue en début d'année 2014. De nouveaux protocoles ont été ajoutés et Suricata peut maintenant extraire et journaliser des éléments des protocoles HTTP, TLS, DNS et SSH. Le tout peut être enregistré dans un fichier au format JSON qui est extensible et s’intègre facilement avec des outils d'analyse de données récents comme Splunk [SPLUNK] ou Elasticsearch [ELK]. Cette dernière solution sera présentée et utilisée dans la suite de l'article.

Pour récupérer des informations de bas niveau, c'est ulogd2, le démon de journalisation de Netfilter qui a été utilisée. Depuis la version 2.0.4, un export JSON des informations est disponible ce qui rend facile l'intégration avec Elasticsearch. La configuration pare-feu mise en place journalise les connexions entrantes sur le système en générant un message pour chaque paquet SYN.

2.4 Analyse des données

Les données collectées sont enregistrées et analysées grâce au trio Elasticsearch, Logstash, Kibana communément appelé ELK. Elasticsearch est un moteur de recherche et d'indexation basé sur Lucene de la fondation Apache. Son architecture est distribuée de manière à assurer le passage à l'échelle lors de l'augmentation de la quantité de données par ajout de nœuds. Elasticsearch peut être vu comme une base de données NoSQL qui utilise la méthode REST pour les requêtes.

Logstash est un logiciel qui convertit les données d'une série de greffons d'entrée vers différents greffons de sortie. Les greffons d'entrée vont de l’acquisition de fichiers simples au traitement d’informations de redis ou rabbitmq en passant par la lecture de Twitter. Les sorties sont également très variées et elles adressent notamment Jira ou IRC même si  l'export vers Elasticsearch est le plus utilisé. Un système de filtres est intercalé entre les greffons d'entrée et de sortie pour pouvoir réaliser des modifications (normalisation par exemple) et des enrichissements (ajout des données geoip par exemple).

Kibana est un visualiseur de données qui est basé sur des tableaux de bord construits dynamiquement par l'utilisateur. La philosophie de l'interface est une approche en entonnoir avec une création de filtres lorsque l'utilisateur clique sur un élément et un rafraîchissement des différents éléments du tableau de bord.

kibana-dashboard

L'ensemble de ces outils est open source et, est, il convient de le noter, très facile à installer.

3. Première analyse

3.1 Volumétrie

Le point de collecte a subi plus de 10000 tentatives d'authentification SSH par jour. Des pointes à 300 essais par minute ont été observées. Dans la plupart des cas, de tels maximums sont liés aux tentatives de bruteforce effectuées par un attaquant unique dont le script est particulièrement agressif.

3.2 Géographie des attaques

La répartition géographique des attaques correspond à ce qui est généralement observé par les utilisateurs de Fail2ban avec plus de 90% provenant de Chine.

classement-pays

Cependant, la distribution des adresses chinoises est intéressante puisque, au moment de l'écriture de cet article, elles sont concentrées sur les réseaux 61.174.15.0/24 et 116.10.191.0/24 et elles semblent toutes être utilisées pour des attaques par bruteforce. Il est donc imaginable que les serveurs de ces réseaux soient dédiés aux scans et aux bruteforce sur certains protocoles comme SSH et qu’il s’agisse d’une véritable infrastructure d'attaque.

3.3 Technologies utilisées

Suricata journalise la version des logiciels clients et serveurs pour toutes les connexions et il est donc possible de connaître les technologies utilisées. Il s'agit majoritairement de libssh [LIBSSH] et libssh2 [LIBSSH2]. Le tableau suivant montre la répartition des événements SSH sur 1 mois environ :

ssh-client-repartition

Parmi les solutions plus exotiques, une des plus fréquentes est « JSCH-0.1.51 » [JSCH] qui est une implémentation en Java de SSH. La répartition géographique de l'utilisation de JSCH pour des bruteforce SSH est bien différente et concerne essentiellement les États-Unis, le Mexique et la France, comme le montre l'image suivante :

jsch-attack

La majeure partie des attaques semble être isolée, une même adresse, scannant et se connectant pour effectuer le bruteforce. Cependant, certaines solutions exotiques utilisent des méthodes plus avancées. C'est par exemple le cas d'une attaque réalisée avec un client nommé « Ruby/Net::SSH_2.9.1 x86_64-linux ». En moins de 20 secondes, 20 essais ont été réalisés depuis 5 pays différents. L'image suivante montre la répartition :

ruby-attack

Réaliser une telle séquence suppose vraisemblablement un serveur central distribuant des tâches à des esclaves. La répartition géographique exotique de ces derniers fait penser à l'utilisation d'un botnet. Cette dernière attaque montre bien que les tentatives de bruteforce SSH reposent sur des solutions variées allant des scripts artisanaux à des solutions technologiquement complexes.

4. Une attaque spécifique

4.1 Pour les fenêtres, c'est la taille qui compte

Les données collectées par ulogd contiennent l'intégralité des entêtes des paquets et sont une source d'informations potentielles sur les technologies utilisées par les attaquants. Il existe en effet de nombreuses techniques pour déterminer le système d'exploitation d'une machine en analysant certaines des caractéristiques des paquets qu'elle a émis.

Si la plupart des techniques nécessitent des opérations mathématiques non accessibles dans Kibana, il est une donnée accessible directement qui en dit déjà beaucoup sur une machine. Il s'agit de la taille de fenêtre TCP à l'ouverture des sessions. La taille de fenêtre est un champ du paquet TCP définissant la quantité de données pouvant être envoyées sans acquittement. L'évolution de la taille de fenêtre au cours de la vie d'une connexion est définie de manière précise dans la RFC 1323 et c'est d'ailleurs un des paramètres utilisés par les pare-feux pour détecter des tentatives d'injection de données. Cependant, la RFC ne définit pas la taille de fenêtre au démarrage de la session et les systèmes d'exploitation ont donc dû choisir « arbitrairement » les valeurs.

La liste suivante montre les valeurs pour différents systèmes :

- 8192: Windows 7 SP1 ;

- 65535: Mac OS X 10.2 – 10.7, Windows XP, Windows 2003, FreeBSD ;

- 14600: Linux ;

- 5840: D'autres Linux.

La valeur de ce champ à l'initialisation de la connexion est donc un indicateur du système d'exploitation et s’agissant d’un des champs collectés par ulogd, il est intéressant de le tracer dans Kibana. Pour cela, il suffit de visualiser les valeurs de la fenêtre TCP pour l'ensemble des paquets ayant le flag SYN présent.

En demandant un « term » sur la valeur de fenêtre, on obtient le résultat suivant pour une période de 24h sur le système de collecte :

tcp-window

On identifie donc les valeurs dans notre précédent tableau pour les deux plus fréquentes fenêtres TCP contrairement à la troisième qui ne s’y trouve pas. Une étude des références sur les valeurs classiquement rencontrées confirme que cette valeur n'est utilisée par aucun système d'exploitation référencé et qu’elle mérite d’être approfondie.

Les barres du graphe dans l'interface de Kibana sont cliquables et le résultat est l'ajout d'un filtre sur la valeur. La mise à jour se fait sur l'intégralité des éléments de la page et la mise en place de ce filtre explicite des informations significatives sur la carte géographique des sources :

geoip-china

Cette taille de fenêtre est uniquement présente en Chine et une étude sur une plage de temps plus longue montre que cette répartition géographique est confirmée. On trouve toutefois trace de cette taille de fenêtre TCP dans quelque pays d'Amérique, mais si l'on limite l'étude au port 22 on exclut alors ces populations qui sont en fait à la recherche de relais mails ou proxy ouverts.

4.2 Analyse en profondeur

Le tableau de présentation des événements individuels est le suivant :

attempt-list

On remarque immédiatement que les ports sources sont tous égaux à 6000. La probabilité d'un tel événement est quasiment nulle, car si les connexions étaient ouvertes par les systèmes d'exploitation des hôtes concernés, les ports sources seraient alors choisis de manière « aléatoire ». Ce choix du port source combiné à la valeur non référencée de la taille de fenêtre indique qu'il s'agit de paquets générés par une socket raw. Une analyse d'un échange montre que l'attaquant envoie deux paquets par séquence, un SYN suivi d'un RST en réponse au SYN ACK. C'est donc un scanner de port utilisant une socket raw et utilisant un modèle de paquet peu conventionnel en ce qui concerne la taille de la fenêtre TCP

En se focalisant sur une IP donnée, on obtient le profil de l'attaque. Le tableau suivant présente les données reçues dans l'ordre chronologique :

complete-seq

On constate donc un scan (port 6000) suivi d'une série de tentatives de connexions SSH. Comme l'indique le port source aléatoire et la taille de fenêtre, il s'agit là de connexions ouvertes par le système d'exploitation et utilisées pour l'attaque bruteforce à proprement dit.

Si l'on regarde au niveau des événements SSH analysés par Suricata on s'aperçoit que le client SSH utilisé est libssh2_1.4.2 pour toutes les adresses IP utilisant la taille de fenêtre 16384.

Au niveau des alertes générées, les machines sont souvent déjà connues et elles apparaissent dans les règles identifiant les machines compromises ou offensives :

complete-seq

Les machines des réseaux 61.174.15.0/24 et 116.10.191.0/24 précédemment mentionnés utilisent toutes cette technique. Cette homogénéité tend à confirmer le côté industriel [1] des attaques effectuées à partir de ces deux réseaux.

L'ensemble de ces traces réseaux a donc permis de caractériser une plate-forme d'attaque par bruteforce qui n'est déployée qu'en Chine.

5. Un honeypot pour collecter les mots de passe

Les données collectées sont très intéressantes, mais il manque l'un des éléments les plus significatifs d'un bruteforce à savoir les couples utilisateur/mot de passe utilisés.

Il existe des solutions complètes comme Kippo [KIPPO] pour simuler une session SSH et ainsi récupérer les commandes lancées par le client, mais comme cela semble beaucoup pour faire une simple récupération des informations d’authentification,le logiciel pshitt [PSHITT] [2] a été développé dans le cadre de cette étude.

Il s'agit d'un serveur SSH basé sur paramiko [PARAMIKO] qui journalise les mots de passe dans un fichier au format JSON et refuse les connexions dans tous les cas.

Pshitt prend la place du serveur SSH et il est donc souhaitable de ne rediriger que le trafic des adresses utilisant des clients SSH non classiques (non OpenSSH dans le cas de l'étude) pour ne pas perdre la possibilité d'accéder en SSH au système. Pour détecter les IP avec des clients suspects, il suffit d'étudier les informations extraites par Suricata. On peut alors utiliser cette information pour mettre les adresses dans une liste exploitée avec Netfilter pour rediriger les tentatives de connexions vers pshitt.

Cette tâche est réalisée par l’outil « Deny On Monitoring » [3] [DOM] développé aussi dans le cadre de cette étude.DOM s'appuie sur ipset [IPSET] qui est un système de gestion d'ensembles développé pour Netfilter. Ipset utilise des structures adaptées afin d'offrir des temps de recherche très courts et de permettre la mise à jour rapide de ses listes. Dans notre cas, nous avons uniquement besoin d'une table d'adresses IP. Et nous allons rediriger l'ensemble des adresses de la liste vers le port 2200 :

# création de l'ensemble

ipset create sofitel hash:ip

# redirige les IP de l'ensemble vers le port 2200 où écoute pshitt

iptables -A PREROUTING -t nat -m set --match-set sofitel src \

-i eth0 -p tcp -m tcp --dport 22 -j REDIRECT --to-ports 2200

Il suffit alors d’exécuter DOM en le configurant afin de rajouter à la liste les adresses n'utilisant pas (-i) un agent OpenSSH. :

./dom -f /usr/local/var/log/suricata/eve.json -i -m OpenSSH -s sofitel

Le code de DOM est un exemple d'utilisation des journaux JSON de Suricata. Sa simplicité montre à quel point il est facile de développer ses propres tâches utilisant les informations extraites par Suricata.

5.1 Résultats

Les comptes massivement attaqués sont root et admin et on trouve au niveau des mots de passe les  combinaisons bien connues, comme l’illustre le tableau suivant qui reprend les données sur sept jours :

pass-user

La récupération des mots de passe a aussi conduit à observer quelques attaques surprenantes comme par exemple ce bruteforce violent basé sur libssh :

user-pass-invert

Il semble que l'attaquant a inversé le champ mot de passe et utilisateur dans son dictionnaire. Le cas présenté provient d'une adresse chinoise, mais une attaque similaire venant de Grèce a aussi été observée.

Conclusion

La mise en place d'une infrastructure de monitoring basée sur Suricata et Ulogd, couplée à un pot de miel dédié a permis de mieux classifier les différentes attaques par bruteforce SSH. L'analyse menée facilement grâce à Elastisearch montre que la variété des attaques est considérable. Les moyens vont du script artisanal déployé sur une unique machine à l’utilisation d’une ferme de serveurs provisionnés automatiquement. Une fois le bruit constitué par les nombreux bruteforce, majoritairement chinois, analysé et nettoyé, les attaques technologiquement plus intéressantes comme ces rares cas distribués géographiquement apparaissent et pourraient être approfondis.

Notes

[1] Le lecteur peu soucieux du politiquement correct peut s'autoriser à lire étatique plutôt qu’industriel.

[2] Nommé d'après une citation de Jacques Chirac : [les attaques] c'est qu'elles font « pschitt ».

[3] DOM, grand bloqueur de scans, a été nommé officieusement ainsi en référence à un homme politique français : « Dom, y nique trop de scans ».

Références

[FAIL2BAN] http://www.fail2ban.org/

[SURICATA] Suricata : http://suricata-ids.org/

[SPLUNK]Site de la société Splunk : http://www.splunk.com/

[ELK] http://www.elasticsearch.org/

[Ulogd] http://www.netfilter.org/projects/ulogd

[LIBSSH] http://www.libssh.org/

[LIBSSH2] http://www.libssh2.org/

[JSCH] http://www.jcraft.com/jsch/

[KIPPO] https://github.com/desaster/kippo

[PSHITT] https://github.com/regit/pshitt

[PARAMIKO] https://github.com/paramiko/paramiko

[DOM] https://github.com/regit/DOM


Sur le même sujet

« Certifier » son serveur mail

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Avoir son propre serveur de mails bien à soi est le rêve de beaucoup d’utilisateurs GNU/Linux. Cependant, depuis quelque temps, les principaux acteurs du net exigent que nous montrions patte blanche avant de transférer ou d'accepter nos courriels. Voyons donc comment faire.

Un œil technique sur les sanctions de la CNIL

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Près de trois quarts des sanctions prononcées par la Commission Nationale de l’Informatique et des Libertés (CNIL) ont parmi leurs causes des vulnérabilités techniques de sécurité. À partir de ce constat, et au prisme de notre expérience à la fois en cybersécurité technique et en protection des données à caractère personnel, nous avons analysé les sanctions de la CNIL publiées sur le site https://www.legifrance.gouv.fr/. Nous avons notamment établi une correspondance avec les catégories de vulnérabilités techniques identifiées dans la nomenclature du top 10 de l'OWASP 2017 (Open Web Application Security Project). Nous avons également étudié les fuites de données majeures survenues en Europe et dans le monde. Il en ressort que les vulnérabilités les plus communes sont liées à l’authentification, au contrôle d’accès et à la protection des données au repos et en transit.

De l’audit de code pendant un Red Team ?

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant un Red Team, l’exhaustivité des découvertes est mise de côté pour privilégier l’efficacité en se concentrant sur l’identification des vulnérabilités à fort impact permettant de mettre rapidement un pied dans le système d’information ciblé.

Tomoyo, le contrôle d’accès facile

Magazine
Marque
GNU/Linux Magazine
Numéro
235
|
Mois de parution
mars 2020
|
Domaines
Résumé

Par un contrôle fin des accès aux fichiers, les logiciels de type Mandatory Access Control (MAC) permettent de lutter efficacement contre le piratage et le vol de données. Tomoyo-linux propose une alternative simple d’utilisation à SELinux.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

Par le même auteur

10 ans de Suricata

Magazine
Marque
MISC
Numéro
100
|
Mois de parution
novembre 2018
|
Domaines
Résumé
Pas besoin d’avoir fait des lettres LA Teen pour savoir que 10 ans est une étape importante. Le projet commencé en 2008 par Victor Julien sous le nom de VIPS pour Victor’s IPS a bien changé. Son évolution fonctionnelle témoigne de la transformation des menaces et les techniques de sécurisation du développement utilisées sont la preuve des progrès réalisés dans ce domaine.

Filtrez votre réseau avec Nftables

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
93
|
Mois de parution
novembre 2017
|
Domaines
Résumé
Vous vous sentez enfin à l’aise avec iptables et là vous apprenez que Nftables est maintenant prêt pour la production. Voici donc quelques clefs pour se préparer au changement et soutenir facilement une discussion avec un fan d'OpenBSD.

Nftables, une révolution dans le pare-feu Linux

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
76
|
Mois de parution
janvier 2015
|
Domaines
Résumé
Après 10 ans d'une domination implacable sur le monde des pare-feu open source, iptables est sur le point d'être remplacé par nftables. Les développeurs de Netfilter ont choisi de revoir leur copie et proposent un nouveau système de filtrage en rupture avec l'existant. Quelles sont leurs motivations et qu'apporte nftables par rapport à son vénérable ancêtre ?

Une étude des bruteforce SSH

Magazine
Marque
MISC
Numéro
76
|
Mois de parution
novembre 2014
|
Domaines
Résumé
Bien que les attaques en bruteforce des SSH fassent partie du bruit blanc du trafic réseau des systèmes connectés, leur étude révèle des profils d'attaquants à l'hétérogénéité intrigante. Leur analyse approfondie grâce à un pot de miel dédié révèle des informations intéressantes sur les agresseurs.