sshfinder

Trova ogni servizio SSH sulla tua rete, valuta se soddisfa i tuoi standard e ricevi una notifica quando qualcosa cambia.

sshfinder è un singolo file Python senza dipendenze richieste. Puntalo su un intervallo CIDR e scopre SSH ovunque sia effettivamente in ascolto — non solo sulla porta 22 — conferma che ciascuno parli davvero SSH, valuta la sua postura crittografica e restituisce un codice di uscita non zero quando qualcosa viola la tua policy.

---

Il problema che risolve

La maggior parte dei team non riesce a rispondere a tre domande sul proprio parco SSH:

1. Quanti servizi SSH abbiamo e dove? Non quante macchine — quanti servizi SSH in ascolto, incluso quello sulla porta 2222 che un appaltatore ha configurato nel 2019.
2. Soddisfano tutti il nostro standard? Login con password disabilitato, nessun cifrario compromesso, non esposti a Terrapin. In modo dimostrabile, non per asserzione.
3. Cosa è cambiato da ieri sera? Una chiave host che si è spostata. Un servizio che è apparso. L'autenticazione con password che è tornata attiva dopo una ricostruzione.

Gli strumenti esistenti rispondono ciascuno a parte di questo e si fermano:

Strumento	Scopre SSH	Lo valuta	Su un intero parco
nmap	sì	superficiale, tramite script NSE	sì
ssh-audit	no — gli fornisci un singolo host	in profondità	no
masscan / zmap	a scala internet	no	sì
sshfinder	sì	sì	sì

Questo divario — scoperta e valutazione e un verdetto, in un unico artefatto — è ciò che questo strumento esiste per colmare. Se devi solo controllare un singolo host che già conosci, usa ssh-audit; va più in profondità su un singolo servizio di quanto faccia questo.

A chi è destinato

• Sicurezza interna e inventario degli asset. Costruisci e mantieni un registro di ogni servizio SSH nel parco, esportato in CSV o JSON.
• Team di piattaforma e SRE con un obbligo di conformità. Dimostra, su base programmata e con un codice di uscita, che nessun host in una VPC accetta il login con password o offre crittografia debole.
• Chiunque gestisca una migrazione post-quantistica. Un numero per quanto del parco non riesca ancora a negoziare lo scambio di chiavi post-quantistico, e esattamente quali servizi siano quelli.

I penetration tester troveranno utili l'audit e il pivot SOCKS, ma lo strumento è modellato attorno all'esecuzione ripetuta della stessa scansione contro un parco che possiedi, non attorno a un impegno una tantum.

---

Avvio rapido

git clone https://github.com/kabiri-labs/sshfinder.git
cd sshfinder
python sshfinder.py 10.0.0.0/24 -p 22,2222

Nessuna installazione, nessuna dipendenza. Richiede Python 3.9+.

Le tre cose che fa, in tre comandi:

# 1. INVENTARIO — che SSH c'è in giro?
python sshfinder.py 10.0.0.0/24 --audit --format csv -o ssh-inventory.csv

# 2. VERDETTO — soddisfa il nostro standard? (esce con 3 se no)
python sshfinder.py 10.0.0.0/24 -p 22,2222 --policy baseline

# 3. DERIVA — cosa è cambiato da ieri sera?
python sshfinder.py 10.0.0.0/24 -p 22,2222 --baseline yesterday.json \
    --fail-on-drift

---

1. Inventario

La scansione di tutte le 65535 porte è l'impostazione predefinita, perché un servizio SSH su una porta non standard è esattamente quello che nessuno ha annotato. Ogni porta aperta viene etichettata, quindi una porta aperta non viene mai contata silenziosamente come 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 conferma è un vero scambio di identificazione RFC 4253, non uno sguardo ai primi byte sul filo. I server che stampano prima un banner legale, che aspettano che il client si identifichi, o il cui banner arriva suddiviso tra segmenti TCP vengono tutti riconosciuti correttamente — ciascuno di questi è un falso negativo in un'implementazione ingenua.

Aggiungi --audit per il quadro completo di ogni servizio:

  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, …

Chiavi host SSH condivise (possibili host condivisi/clonati):
  SHA256:T/ZM4jOL4amTsO5K3AaCdg2...
    -> 10.0.0.5:22, 10.0.0.9:22

Quell'ultimo blocco merita attenzione: una chiave host riutilizzata tra macchine di solito significa VM clonate o un'immagine condivisa, e significa che compromettere un host compromette l'identità di tutti.

Prontezza post-quantistica

OpenSSH 10.0 ha reso mlkem768x25519-sha256 lo scambio di chiavi predefinito, e 10.1 avverte che le sessioni classiche sono aperte alla cattura store now, decrypt later. --pq-report risponde direttamente alla domanda a livello di parco, usando solo il KEXINIT — quindi non richiede librerie di terze parti:

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 categoria pre-standard è quella che coglie di sorpresa. Un server che pubblicizza [email protected] o una bozza Kyber sembra post-quantistico in un dump di algoritmi, ma OpenSSH ha eliminato quel set di parametri ritirato nel 2020 — quindi un client attuale non trova alcun metodo comune e ripiega sulla crittografia classica. Contato come pronto, sarebbe peggio che non guardare affatto.

2. Verdetto

Un report descrive un problema. Una policy asserisce un problema e può far fallire una build:

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

Tre policy sono incluse — baseline, strict e pq — denominate per il risultato che impongono piuttosto che per una distribuzione. Le regole portano una severità fail o warn e --fail-on decide quali soglie, quindi un team può adottare uno standard più severo prima come avviso e promuoverlo in seguito senza modificare nulla.

Scrivi le tue come JSON:

{
  "name": "house-rules",
  "description": "What we expect of every SSH service.",
  "rules": [
    {"check": "password_auth", "severity": "fail"},
    {"check": "terrapin", "severity": "fail"},
    {"check": "post_quantum", "require": "ready", "severity": "warn"},
    {"check": "forbid", "field": "ciphers",
     "algorithms": ["3des-cbc", "arcfour"], "severity": "fail"},
    {"check": "require", "field": "kex_algorithms",
     "algorithms": ["curve25519-sha256"], "severity": "fail"}
  ]
}

Controlli: password_auth, terrapin, weak_algorithms, post_quantum (con require: ready, legacy o absent), e forbid / require su un field di kex_algorithms, host_key_algorithms, ciphers o macs.