Analisi forense degli attacchi SSH: rilevamento, ricostruzione della timeline e analisi di sicurezza

Sintesi

Questa ricerca documenta un esperimento originale e controllato e il relativo strumento di analisi. Una macchina virtuale Linux ha generato record OpenSSH reali mentre uno script operatore eseguiva accessi riusciti, un singolo tentativo con password errata, fallimenti concentrati su un account esistente e fallimenti su un account inesistente. Uno strumento Python conserva la provenienza dei record, ricostruisce una timeline UTC e applica regole trasparenti di revisione basate su finestre mobili.

La cattura di controllo con le penalità disabilitate contiene 11 record primari di autenticazione fallita e 3 record di autenticazione accettata. Il registro indipendente delle azioni concorda con questi conteggi. Le notifiche associate di utente inesistente vengono conservate senza essere conteggiate come ulteriori tentativi tramite password. L’esperimento misura il comportamento di questo piccolo corpus etichettato; non stima l’accuratezza del rilevamento sul traffico Internet né dimostra la compromissione di un account.

Domanda di ricerca e contributo

Una timeline riproducibile delle autenticazioni SSH può distinguere un errore isolato da sequenze concentrate di fallimenti senza sovrastimare la compromissione? Il contributo consiste in una catena sperimentale completa e verificabile: scenari dichiarati, record reali del daemon, un registro indipendente del client, un parser che conserva il testo sorgente, rilevamento parametrico, analisi della sensibilità alla soglia ed evidenze scaricabili.

La ricerca non dichiara una nuova vulnerabilità SSH, una CVE o l’invenzione di una nuova tecnica di analisi dei log. Il contributo originale è costituito dall’esperimento, dal dataset generato e dallo strumento di analisi. Anche utenti autorizzati possono commettere errori: fallimenti e successi successivi richiedono quindi una revisione, senza portare automaticamente a conclusioni sulla presenza di un attaccante.

Metodologia e isolamento del laboratorio

Il laboratorio ha usato Alpine Linux 3.24.2, Linux 6.18.52-0-virt, OpenSSH 10.3p1 / OpenSSL 3.5.8, VirtualBox 7.2.20r175154. L’avvio è avvenuto da un’immagine Alpine ufficiale verificata con SHA-256, con una modifica locale documentata della console di avvio. La VM non aveva dischi rigidi collegati né schede di rete abilitate; la console seriale consentiva il controllo e l’esportazione delle evidenze. Il sito di produzione è stato utilizzato soltanto come destinazione della pubblicazione.

Il daemon dedicato era in ascolto su 127.0.0.1:2222. L’autenticazione tramite password era abilitata esclusivamente per generare record controllati. L’accesso root era disabilitato, i client utilizzavano soltanto identità create appositamente per il laboratorio e client e server limitavano ogni connessione a un solo tentativo tramite password. La configurazione pubblicata documenta le impostazioni effettive: si tratta di scelte sperimentali, non di una configurazione consigliata per la produzione.

Durante la preparazione del laboratorio, una prova pilota iniziale è fallita a livello di trasporto: il sistema Alpine ospite, eseguito interamente in RAM, non aveva un indirizzo loopback configurato e il client ha riportato Network unreachable. Questi errori di trasporto non sono stati conteggiati come autenticazioni fallite; il corpus originale del server della prova pilota non è stato esportato. Lo script è stato corretto configurando il loopback e l’esperimento è ripartito da un sistema ospite appena avviato. La cattura autentica del client e dell’interfaccia della prova pilota e le note di esclusione sono incluse separatamente nel pacchetto scaricabile.

Sono conservate separatamente due esecuzioni: una con le penalità native predefinite e una con PerSourcePenalties no, limitato a questo controllo offline. Il piano degli scenari e il registro del client sono indipendenti dal parser. Le connessioni riuscite hanno eseguito soltanto un innocuo comando di marcatura. Nella prova di controllo ogni fallimento ha utilizzato una password deliberatamente errata; non è stata effettuata alcuna ricerca di credenziali. L’errore isolato è separato dagli scenari concentrati da un intervallo superiore alla finestra di 60 secondi del rilevatore. Alla sequenza è seguito un accesso esplicitamente legittimo, per verificare la regola di revisione senza interpretare il successo come compromissione.

Gestione dei timestamp. Il sistema ospite utilizzava UTC e aveva ereditato l’orologio del sistema host VirtualBox. La VM offline non poteva sincronizzare l’orologio tramite la rete. Sono conservati i record dell’ambiente e dei tempi del sistema ospite, insieme agli orari UTC di invio ed esportazione del sistema host. L’accuratezza dell’orologio e la deriva non sono state calibrate indipendentemente; i timestamp syslog di BusyBox hanno precisione di un secondo. Il parser richiede anno e fuso orario espliciti per i record syslog BSD, conserva il testo originale e produce timestamp UTC nel formato RFC 3339. La precisione al secondo viene mantenuta; timestamp uguali non stabiliscono un ordine causale tra connessioni separate.

Conservazione e provenienza delle evidenze

Raccolta, esame, analisi e documentazione seguono il processo descritto in NIST SP 800-86. I byte originali del daemon sono conservati in sshd-syslog.log; il registro delle azioni, le informazioni sulle versioni, la configurazione del daemon, lo script dell’esperimento e le note di acquisizione sono inclusi nella pubblicazione. I report derivati vengono prodotti da una copia del log.

Il file originale sshd-syslog.log contiene 9870 byte. Il suo digest SHA-256 è:

b6d85e3d58d5cf626d30a8195a23ba50ea466ce4cd186b4a93ce60c016fa2d07

Il manifest degli hash delle evidenze consente di verificare la coerenza di ogni file pubblicato. Un hash non dimostra indipendentemente chi abbia generato un log, che il log sia completo o che il suo orologio fosse accurato. Si tratta di un’acquisizione di ricerca riproducibile con provenienza documentata, senza pretendere una catena di custodia legale attestata da testimoni indipendenti.

Il dataset pubblico contiene soltanto identificativi di laboratorio e indirizzi loopback. Credenziali, chiavi private, dettagli dell’hosting e file locali estranei alla ricerca sono esclusi dalla pubblicazione. Il report leggibile automaticamente contiene l’hash dell’input, i parametri del parser e i conteggi di copertura; timeline.csv conserva i riferimenti alle righe sorgenti.

Riga 16 del file originale sshd-syslog.log · Errore di digitazione isolato e benigno; i fallimenti successivi sono separati da 65 secondi.

Oct 10 19:15:21 cybery-ssh-lab auth.info sshd-session[1825]: Failed password for labuser from 127.0.0.1 port 40324 ssh2

Riga 44 del file originale sshd-syslog.log · Notifica di utente inesistente come contesto; non è un’autenticazione fallita aggiuntiva.

Oct 10 19:16:26 cybery-ssh-lab auth.info sshd-session[1875]: Invalid user invaliduser from 127.0.0.1 port 51076

Riga 68 del file originale sshd-syslog.log · Successo esplicitamente legittimo dopo fallimenti controllati; indicatore da revisionare, non compromissione.

Oct 10 19:16:26 cybery-ssh-lab auth.info sshd-session[1903]: Accepted password for labuser from 127.0.0.1 port 51114 ssh2

Risultati verificati: controllo con penalità disabilitate

• Tutte le 14 azioni della prova di controllo corrispondono a 14 record primari del daemon per account, esito, sorgente loopback e timestamp nativo compreso nell’intervallo dell’azione del client. I client con esito positivo hanno restituito 0; quelli con esito negativo 255.
• Il controllo contiene 11 record di password errata: un errore di digitazione isolato e benigno, sei fallimenti contro labuser e quattro contro invaliduser. Le quattro notifiche associate di utente inesistente non aggiungono altre quattro autenticazioni fallite.
• L’errore isolato precede di 65 secondi il primo fallimento della sequenza concentrata. Il rilevatore predefinito, con soglia di cinque fallimenti in 60 secondi, produce 6 punti finali di finestre sovrapposte e 1 successo successivo ai fallimenti da sottoporre a revisione; quest’ultimo accesso è esplicitamente legittimo.
• La prova separata con le impostazioni native predefinite registra 2 password accettate, 5 password errate e 7 connessioni rifiutate dal controllo nativo, a fronte di 12 risultati del client con stato 255. L’ultimo accesso legittimo pianificato è stato rifiutato prima dell’autenticazione tramite password.
• Gli hash delle evidenze originali sono stati verificati dopo l’esportazione dalla console e un verificatore indipendente concorda con l’analizzatore. Questo piccolo dataset controllato non dimostra l’accuratezza del rilevamento in condizioni reali né la compromissione di un account.

Il parser ha riconosciuto 35 righe contenenti eventi su 74 righe di input. Riporta 37 righe relative a SSH al di fuori dei modelli riconosciuti e 2 righe estranee a SSH. La copertura è dichiarata per rendere visibili i tipi di messaggio omessi; non è una misura del richiamo (recall). Il log originale resta disponibile per l’ispezione manuale.

Le penalità native modificano quali tentativi raggiungono l’autenticazione

Un’esecuzione separata ha mantenuto le impostazioni PerSourcePenalties predefinite della versione installata. Il suo registro contiene 14 azioni del client, ma il daemon ha registrato soltanto 2 password accettate e 5 password errate, seguite da 7 connessioni rifiutate dalle penalità native per sorgente. L’ultimo accesso legittimo pianificato ha restituito lo stato 255 del client e non ha mai prodotto un record di autenticazione accettata.

Il daemon ha registrato esplicitamente l’attivazione di una penalità, poi il rifiuto di connessioni con la motivazione penalty: failed authentication. La configurazione effettiva riporta authfail:5, min:15 e max:600. Nella prova con impostazioni predefinite, dopo l’errore isolato si sono verificati quattro fallimenti di autenticazione concentrati; le penalità native accumulate hanno quindi rifiutato le connessioni successive. I record delle penalità descrivono il contesto della politica applicata, non ulteriori password errate.

Prova con la politica predefinita · riga 37 del log originale

Oct 10 19:12:25 cybery-ssh-lab auth.info sshd[1792]: srclimit_penalise: 127.0.0.1/32: activating ipv4 penalty of 19.813 seconds for penalty: failed authentication

Prova con la politica predefinita · riga 38 del log originale

Oct 10 19:12:25 cybery-ssh-lab auth.info sshd[1792]: drop connection #0 from [127.0.0.1]:52290 on [127.0.0.1]:2222 penalty: failed authentication

Implicazione forense: un risultato non nullo del client SSH non dimostra che una password sia risultata errata. Gli errori di trasporto e i rifiuti nativi delle connessioni devono essere distinti dagli esiti di autenticazione. In questa cattura con la politica predefinita, la regola dei cinque fallimenti non ha raggiunto la soglia, benché il registro mostri una sequenza concentrata di tentativi di connessione: il controllo nativo ha modificato i record di autenticazione disponibili. È un’interazione osservata tra due controlli in questo corpus, non una stima generale dell’attività degli attaccanti o dell’efficacia del rilevatore.

La documentazione OpenSSH descrive il meccanismo delle penalità per sorgente; le note di rilascio di OpenSSH 9.8 ne descrivono l’introduzione. La build installata e le impostazioni effettive, non la sola documentazione corrente, stabiliscono la configurazione di questo esperimento. La successiva prova di controllo ha utilizzato esplicitamente PerSourcePenalties no per consentire all’intera sequenza pianificata di raggiungere l’autenticazione. Questa modifica è limitata all’esperimento offline e non è una raccomandazione per la produzione.

Sono pubblicati il log originale della prova con impostazioni predefinite, il registro delle azioni, l’analisi JSON separata, la trascrizione del client, i metadati di acquisizione e gli hash. I record di rifiuto non contengono il nome dell’account; il registro deliberatamente sequenziale, proveniente da un’unica sorgente, e i timestamp supportano il confronto. Il solo ordine dei log nello stesso secondo non consentirebbe di attribuire attività concorrenti su un host reale.

Regole di rilevamento e sensibilità alla soglia

La regola predefinita segnala una sorgente quando almeno cinque autenticazioni primarie fallite ricadono in una finestra inclusiva di 60 secondi. Il raggruppamento usa l’indirizzo di rete osservato; tutte le connessioni di questo esperimento condividono il loopback, quindi il risultato descrive una sola sorgente locale. Una regola distinta segnala per revisione un’autenticazione accettata quando la stessa sorgente e lo stesso account presentano almeno cinque fallimenti precedenti negli ultimi 60 secondi.

Lo strumento registra gli ID degli eventi di evidenza per ogni punto finale che soddisfa la soglia. Finestre sovrapposte possono produrre più punti finali per la stessa sequenza. Il numero di punti finali non rappresenta il numero di attacchi o incidenti distinti. Un successo dopo i fallimenti è un indicatore da revisionare: questo esperimento lo produce deliberatamente con un accesso legittimo.

Modificare la soglia cambia ciò che la regola segnala, senza alterare le evidenze sottostanti. In alcuni ambienti soglie più basse segnalano anche più errori ordinari. L’errore isolato e benigno di questo esperimento non raggiunge la soglia predefinita. Una sola cattura di piccole dimensioni non consente stime generalizzabili di precisione, richiamo (recall) o falsi positivi.

Il comportamento controllato di ripetizione delle password è coerente con la categoria descritta da MITRE ATT&CK T1110.001, Password Guessing. Questa classificazione descrive il comportamento dell’esperimento e non attribuisce l’attività a un attore ostile. Nessuna password è stata scoperta per tentativi.

Ricostruzione e interpretazione della timeline

La cattura di controllo normalizzata si estende da 2026-10-10T19:15:20Z a 2026-10-10T19:16:26Z. Ogni record riconosciuto conserva ID dell’evento, numero della riga sorgente, testo originale, origine del timestamp, tipo di evento e, se disponibili, nome utente, ID del processo, indirizzo e porta sorgente. I record sono ordinati per tempo normalizzato; in caso di parità viene mantenuto l’ordine delle righe originali.

Una notifica Invalid user e un successivo record Failed password for invalid user possono descrivere la stessa connessione del client. Il parser conteggia il secondo come fallimento primario e conserva il primo come contesto. Correlare indirizzo, porta sorgente e PID del daemon può aiutare a esaminare una connessione, ma il riutilizzo dei PID e i campi mancanti limitano questa correlazione.

Un record Accepted password dimostra che il daemon ha accettato quel metodo di autenticazione. Non identifica la persona che controlla il client né descrive gli effetti successivi. La trascrizione indipendente del client documenta il comando innocuo eseguito nell’esperimento; i soli log di autenticazione non dimostrerebbero l’esecuzione di comandi su un generico host sottoposto a indagine.

È possibile esaminare la timeline CSV completa, gli eventi strutturati e i riferimenti alle evidenze nel report, insieme al log originale e al registro delle azioni. I codici di uscita negativi del client corroborano gli scenari controllati; non sostituiscono le evidenze del daemon.

Limitazioni e minacce alla validità

• I dataset provengono da una sola configurazione di VM, una sola build di OpenSSH, due brevi sequenze scelte deliberatamente e una prova pilota di configurazione esclusa. Mancano traffico di fondo, sorgenti distribuite, NAT, attaccanti reali e politiche di autenticazione di produzione.
• Tutti i tentativi provengono dal loopback. Non sono supportate inferenze sulla posizione geografica di un attaccante, sulla reputazione della sorgente o su tentativi distribuiti di password spraying.
• Le soglie sono euristiche sperimentali trasparenti, non classificatori calibrati. Numerosi fallimenti ripetuti possono derivare da uno script difettoso, credenziali non aggiornate o errori umani.
• Versioni di OpenSSH, integrazione PAM, logging della distribuzione, localizzazione, rotazione dei log ed esportazioni di journald possono modificare i record disponibili. Le righe non riconosciute sono rese consultabili; lo strumento non è un parser universale per SSH.
• Il formato syslog BSD non contiene anno e offset UTC espliciti. L’anno e il fuso orario forniti per questa acquisizione sono informazioni di contesto esterne. Log che attraversano il cambio d’anno o mescolano fusi orari richiedono una gestione separata; lo strumento non deduce silenziosamente la cronologia mancante.
• La precisione dei timestamp e la procedura documentata di impostazione dell’orologio della VM limitano l’affidabilità della timeline. I log possono essere modificati, persi o registrati selettivamente; i manifest di integrità non dimostrano completezza o autenticità indipendente.
• I log di autenticazione SSH non mostrano tutti i comandi della sessione, la persistenza, i movimenti laterali o gli accessi ai dati. Questa ricerca non pretende di costituire un’indagine completa sull’endpoint.
• La prova con la politica nativa ha richiesto una fase manuale documentata di finalizzazione, dopo l’arresto immediato causato dal rifiuto dell’accesso legittimo. Ogni prova è stata conservata separatamente; non sono disponibili intervalli di confidenza basati su esecuzioni ripetute.
• L’articolo e il codice sono stati preparati con assistenza dell’IA nel processo di pubblicazione dell’autore indicato. I risultati provengono da attività realmente eseguite nel laboratorio e dalle evidenze fornite; non viene dichiarata alcuna revisione scientifica esterna o approvazione da parte di programmi di verifica.

Analisi di sicurezza e mitigazioni pratiche

Per un servizio in produzione, valutare autenticazione tramite chiavi o certificati, disabilitare le password quando operativamente possibile, vietare l’accesso diretto root, limitare gli utenti ammessi e ridurre l’esposizione di rete mediante VPN o elenco di indirizzi amministrativi consentiti. Dove le password restano necessarie, considerare un secondo fattore configurato esplicitamente tramite AuthenticationMethods. Verificare le modifiche rispetto alla versione OpenSSH installata e provarle senza impedire l’accesso agli amministratori.

MaxAuthTries limita i tentativi all’interno di una connessione; non impone un limite globale tra connessioni nuove. Affiancare controlli adeguati sulle connessioni e una politica monitorata di limitazione della frequenza. Il blocco automatico deve tenere conto degli indirizzi IP condivisi e prevedere una procedura di recupero. Una soglia del laboratorio loopback non va trasferita automaticamente in produzione.

Conservare centralmente i log di autenticazione, sincronizzare in modo coerente gli orologi in UTC, documentare la deriva, definire la conservazione e monitorare le interruzioni nella raccolta. Limitare l’accesso ai log e preservare le evidenze originali prima della normalizzazione. LogLevel VERBOSE può supportare l’indagine sulle autenticazioni; il logging DEBUG può esporre informazioni sensibili e deve essere limitato con attenzione. Correlare gli avvisi di autenticazione con modifiche autorizzate, attività delle sessioni e telemetria degli endpoint prima di formulare conclusioni.

Riprodurre l’esperimento e verificare il codice sorgente

Il pacchetto di riproducibilità include evidenze reali, risultati dell’analisi, codice sorgente Python e test, script di laboratorio, metadati di acquisizione e istruzioni. Il laboratorio non espone endpoint su Internet. Il codice è anche scaricabile direttamente come ssh_forensic.py.

1. Leggere il README incluso, le note di acquisizione e gli hash. Utilizzare una VM Linux usa e getta senza schede di rete, con i pacchetti OpenSSH documentati disponibili offline.
2. Eseguire lo script di laboratorio incluso come root nella VM usa e getta. Lo script crea soltanto il proprio account di laboratorio, credenziali temporanee e un daemon dedicato sul loopback, esegue gli scenari dichiarati e acquisisce log reali. Non utilizzarlo mai su un sistema di produzione.
3. Esportare i file pubblici delle evidenze tramite la console o un meccanismo offline equivalente, escludendo password e chiavi private. Conservare i byte originali e documentare il contesto dell’acquisizione.
4. Eseguire l’analizzatore Python sulla cattura fornita oppure su una nuova cattura specificando anno e fuso orario effettivi. Ripetere l’esperimento modifica timestamp, PID, porte e hash; la corrispondenza va valutata in base agli scenari e al significato dei record.

python -m unittest discover -s tool -p test_ssh_forensic.py -v
python tool/ssh_forensic.py \
  --input evidence/sshd-syslog.log \
  --output analysis-reproduced \
  --year 2026 --timezone UTC \
  --threshold 5 --window 60

Python 3.10 o successivo è sufficiente per l’analizzatore, che usa soltanto la libreria standard. report.json, timeline.csv, il report Markdown e i grafici SVG sono artefatti derivati. Il README incluso illustra il confronto con il registro delle azioni e i comandi di verifica degli hash. Nuove analisi devono conservare i propri input e metadati di acquisizione.

Riferimenti

1. OpenSSH: sshd(8) — esecuzione del daemon, logging e verifica della configurazione.
2. OpenSSH: sshd_config(5) — controlli di autenticazione e logging; consultare la versione installata per verificarne la disponibilità.
3. NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response — raccolta, esame, analisi e documentazione delle evidenze.
4. IETF RFC 3339: Date and Time on the Internet — timestamp normalizzati.
5. MITRE ATT&CK T1110.001: Password Guessing — classificazione comportamentale dei fallimenti ripetuti e controllati.

Riferimenti verificati il 2026-10-10. Questa ricerca non è stata approvata né avallata da Anthropic. La pubblicazione documenta una pratica di ricerca; non dichiara idoneità o accettazione in alcun programma di verifica.