Découverte parallèle de services SSH et auditeur de sécurité qui scanne n'importe quel port, valide les bannières SSH, et audite les méthodes d'authentification, les faiblesses cryptographiques, la vulnérabilité Terrapin et les clés d'hôte réutilisées sur des hôtes et des plages CIDR.
Trouvez chaque service SSH sur votre réseau, jugez s'il répond à votre norme, et soyez informé lorsque cela change.
sshfinder est un fichier Python unique sans dépendances requises. Pointez-le
vers une plage CIDR et il découvre SSH partout où il écoute réellement — pas
seulement sur le port 22 — confirme que chacun parle vraiment SSH, évalue sa
posture cryptographique, et renvoie un code de sortie non nul lorsque quelque
chose échoue à votre politique.
La plupart des équipes ne peuvent pas répondre à trois questions concernant leur propre parc SSH :
Les outils existants répondent chacun à une partie de cela et s'arrêtent là :
| Outil | Découvre SSH | L'évalue | Sur un parc entier |
|---|---|---|---|
nmap | oui | superficiellement, via les scripts NSE | oui |
ssh-audit | non — vous lui donnez un seul hôte | en profondeur | non |
masscan / zmap | à l'échelle d'Internet | non | oui |
sshfinder | oui | oui | oui |
Cette lacune — découverte et évaluation et un verdict, dans un seul artefact — est
ce que cet outil existe pour combler. Si vous n'avez besoin que d'auditer un seul hôte que vous
connaissez déjà, utilisez ssh-audit ; il va
plus en profondeur sur un service unique que celui-ci.
Les testeurs d'intrusion trouveront l'audit et le pivot SOCKS utiles, mais l'outil est conçu autour de l'exécution répétée de la même analyse sur un parc que vous possédez, et non autour d'une mission ponctuelle.
git clone https://github.com/kabiri-labs/sshfinder.git
cd sshfinder
python sshfinder.py 10.0.0.0/24 -p 22,2222
Aucune installation, aucune dépendance. Nécessite Python 3.9+.
Les trois choses qu'il fait, en trois commandes :
# 1. INVENTAIRE — quel SSH est présent ?
python sshfinder.py 10.0.0.0/24 --audit --format csv -o ssh-inventory.csv
# 2. VERDICT — répond-il à notre norme ? (sortie 3 sinon)
python sshfinder.py 10.0.0.0/24 -p 22,2222 --policy baseline
# 3. DÉRIVE — qu'est-ce qui a changé depuis la nuit dernière ?
python sshfinder.py 10.0.0.0/24 -p 22,2222 --baseline yesterday.json \
--fail-on-drift
L'analyse des 65535 ports est la valeur par défaut, car un service SSH sur un port non standard est précisément celui que personne n'a consigné. Chaque port ouvert est étiqueté, de sorte qu'un port ouvert n'est jamais silencieusement compté comme un port SSH :
=== 10.0.0.5 ===
open: 10.0.0.5:22 [SSH], 10.0.0.5:8080 [not ssh]
SSH 10.0.0.5:22 (SSH-2.0-OpenSSH_7.4)
La confirmation est un véritable échange d'identification RFC 4253, pas un simple coup d'œil aux premiers octets sur le fil. Les serveurs qui affichent d'abord une bannière légale, qui attendent que le client s'identifie, ou dont la bannière arrive fragmentée sur plusieurs segments TCP sont tous reconnus correctement — chacun de ces cas est un faux négatif dans une implémentation naïve.
Ajoutez --audit pour obtenir l'image complète de chaque service :
SSH 10.0.0.5:22 (SSH-2.0-OpenSSH_7.4)
host key: ssh-ed25519 SHA256:T/ZM4jOL4amTsO5K3AaCdg2...
auth: publickey, password [!] password auth enabled
[!] Terrapin (CVE-2023-48795): VULNERABLE
[!] weak ciphers: aes128-cbc
aes128-cbc [weak]: CBC mode is vulnerable to the SSH plaintext-recovery attack (CVE-2008-5161) and, …
Clés d'hôte SSH partagées (hôtes partagés/clonés possibles) :
SHA256:T/ZM4jOL4amTsO5K3AaCdg2...
-> 10.0.0.5:22, 10.0.0.9:22
Ce dernier bloc mérite d'être connu : une clé d'hôte réutilisée entre machines signifie généralement des VM clonées ou une image partagée, et cela signifie que compromettre un hôte compromet l'identité de tous les autres.
OpenSSH 10.0 a fait de mlkem768x25519-sha256 l'échange de clés par défaut, et 10.1
avertit que les sessions classiques sont ouvertes à la capture stockez maintenant, déchiffrez plus tard.
--pq-report répond directement à la question au niveau du parc, en utilisant uniquement le
KEXINIT — il ne nécessite donc aucune bibliothèque tierce :
python sshfinder.py 10.0.0.0/24 -p 22,2222 --pq-report
Post-quantum readiness:
1/3 service(s) negotiate post-quantum key exchange with a current client
[!] no PQ key exchange offered (1):
10.0.0.2:22
[!] pre-standard PQ only (1) - looks post-quantum but is not:
10.0.0.3:22
2 service(s) exposed to store-now-decrypt-later capture; upgrade to OpenSSH 9.0+
La catégorie pre-standard est celle qui piège les gens. Un serveur
annonçant [email protected] ou un brouillon Kyber semble
post-quantique dans un dump d'algorithmes, mais OpenSSH a abandonné cet ensemble de paramètres
retiré en 2020 — un client actuel ne trouve donc aucune méthode commune et retombe
sur la cryptographie classique. S'il était compté comme prêt, ce serait pire que de ne pas
regarder du tout.
Un rapport décrit un problème. Une politique affirme un problème, et peut faire échouer une construction :
python sshfinder.py 10.0.0.0/24 -p 22,2222 --policy baseline; echo "exit $?"
Policy 'baseline':
No password login, no Terrapin exposure, no weak algorithms.
1/3 service(s) pass
[FAIL] 1 service(s):
10.0.0.3:22
- password_auth: password login accepted: publickey, password
- terrapin: vulnerable to Terrapin (CVE-2023-48795)
- post_quantum (warn): post-quantum readiness is absent, ready required
[warn] 1 service(s):
10.0.0.2:22
- post_quantum (warn): post-quantum readiness is absent, ready required
exit 3
Trois politiques sont intégrées — baseline, strict et pq — nommées pour le
résultat qu'elles imposent plutôt que pour une distribution. Les règles portent une sévérité fail ou
warn et --fail-on décide quelles portes sont franchies, afin qu'une équipe puisse adopter
un seuil plus strict comme avertissement d'abord et le promouvoir plus tard sans rien modifier.
Écrivez la vôtre en JSON :