Perché non basta scaricare i file manualmente
Scaricare file da un server FTP con FileZilla o un qualsiasi client FTP non ha alcun valore probatorio. Il download manuale non produce hash crittografici dei file scaricati, non documenta lo stato del server prima del download, non registra i comandi scambiati con il server, non preserva la catena di custodia e non appone alcuna marca temporale. In sede giudiziale, la controparte può legittimamente contestare che i file siano stati modificati dopo il download, che il server contenesse altri file non scaricati, o che il download sia avvenuto in una data diversa da quella dichiarata. C.E.R.T.O. Desktop 3.1 risolve ciascuno di questi problemi con un processo di acquisizione forense strutturato: snapshot del server, download in modalità binaria con hash in streaming, log del protocollo FTP, analisi dell'infrastruttura di rete e marca temporale RFC 3161.
L'interfaccia di acquisizione FTP
Configura la connessione
La prima schermata consente di configurare tutti i parametri di connessione al server. Si seleziona il protocollo tra FTP (porta 21, testo in chiaro), FTPS (porta 21 o 990, crittografia TLS) e SFTP (porta 22, tunnel SSH). Si inseriscono host, porta, nome utente e password. Per le connessioni SFTP è possibile caricare una chiave privata (.pem, .ppk) in alternativa alla password.
Sono disponibili preset di configurazione per i principali provider di hosting — Aruba, OVH e SiteGround — che precompilano host e porta con i valori corretti. Alla connessione, il software esegue il rilevamento automatico del software server analizzando il banner 220, i comandi SYST, FEAT e STAT: identifica ProFTPD, vsftpd, Pure-FTPd, FileZilla Server, Microsoft IIS FTP e OpenSSH.
Esplora il server e seleziona
Prima di scaricare qualsiasi file, C.E.R.T.O. esegue uno snapshot completo del server: una scansione ricorsiva di tutte le directory e i file presenti, con registrazione di nome, dimensione, data di modifica, permessi, proprietario e gruppo. Questo snapshot costituisce la prova dello stato del server prima del download.
Il contenuto del server viene presentato con una navigazione ad albero. Sono disponibili tre modalità di acquisizione:
- Ricorsiva — scarica l'intero contenuto del server partendo dalla directory corrente
- Directory singola — scarica solo i file nella directory selezionata, senza sottocartelle
- Selezione manuale — l'utente seleziona singoli file e cartelle dall'albero
L'interfaccia mostra il conteggio dei file, la dimensione stimata totale e l'anteprima del costo in slot (1 slot per ogni MB, arrotondato per eccesso).
Acquisizione e report
Avviata l'acquisizione, ogni file viene scaricato in modalità binaria TYPE I (nessuna conversione CRLF/LF). Durante il download, il software calcola simultaneamente quattro hash crittografici — MD5, SHA-1, SHA-256, SHA-512 — tramite stream-hashing: i dati vengono processati durante il transito senza necessità di una seconda lettura del file.
Al termine del download, viene eseguita una verifica di coerenza confrontando le dimensioni registrate nello snapshot con quelle dei file effettivamente scaricati: qualsiasi discrepanza viene segnalata nel report.
Il software effettua quindi l'analisi dell'infrastruttura di rete del server: risoluzione DNS (record A, AAAA, PTR, MX, NS, TXT), interrogazione WHOIS, traceroute, reverse IP lookup e misurazione della latenza TCP sulle porte 21, 22, 80 e 443.
Viene generato un report di acquisizione in formato PDF e TXT strutturato in 11 sezioni che documenta ogni fase del processo. Il report e tutti i file di prova vengono infine firmati con marca temporale RFC 3161 (FreeTSA) e archiviati in un file ZIP.
Esempio reale: acquisizione di un server FTP di test
| Protocollo | SFTP |
| Host | sftp.esempio.it |
| Porta | 22 |
| Software server | OpenSSH_8.9 |
| File acquisiti | 47 file in 12 directory |
| Dimensione totale | 23,4 MB |
| Costo in slot | 24 slot (1 slot/MB, arrotondato per eccesso) |
| ID acquisizione | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| Data acquisizione | GG/MM/AAAA ore HH:MM |
I file generati dall'acquisizione
Al termine dell'acquisizione, la cartella di output contiene i seguenti file, organizzati per categoria.
RAPPORTO E LOG
| File | Descrizione |
|---|---|
| rapporto-acquisizione.pdf | Report completo in 11 sezioni: dati connessione, snapshot server, elenco file con hash, verifica coerenza, analisi rete, marca temporale |
| rapporto-acquisizione.txt | Versione testuale del report, leggibile senza software aggiuntivo e indicizzabile per ricerca full-text |
| rapporto-acquisizione.tsr | Marca temporale RFC 3161 (TimeStampResp) applicata all'hash SHA-256 del report PDF tramite FreeTSA |
| acquisizione-log.txt | Log cronologico completo di tutte le operazioni eseguite dal software durante l'acquisizione |
| connessione-info.txt | Dettagli della connessione: protocollo, host, porta, utente, software server, banner, funzionalità supportate (FEAT) |
| timestamp-info.json | Metadati della marca temporale in formato JSON: TSA utilizzata, algoritmo hash, data/ora certificata, serial number |
| {id}-hashes.json | File JSON con gli hash MD5, SHA-1, SHA-256 e SHA-512 di ogni file acquisito, indicizzati per percorso |
| verifica-integrita.sh | Script Bash per la verifica automatica degli hash su sistemi macOS e Linux (usa shasum e md5) |
| verifica-integrita.bat | Script batch per la verifica automatica degli hash su sistemi Windows (usa certutil) |
SERVER SNAPSHOT
| File | Descrizione |
|---|---|
| server-snapshot.json | Snapshot strutturato in formato JSON dell'intero contenuto del server: percorsi, dimensioni, date di modifica, permessi, proprietario e gruppo per ogni file e directory |
| server-snapshot.txt | Versione testuale dello snapshot, formattata come listing di directory leggibile |
| server-listing-raw.json | Risposte MLSD/LIST grezze restituite dal server, senza alcuna elaborazione — prova di ciò che il server ha effettivamente comunicato |
PROTOCOLLO FTP
| File | Descrizione |
|---|---|
| ftp-protocol-log.json | Log completo del protocollo FTP: ogni comando inviato e ogni risposta ricevuta, con timestamp millisecondi. Registra la sequenza esatta delle operazioni (USER, PASS, TYPE I, MLSD, RETR, ecc.) |
INFRASTRUTTURA RETE
| File | Descrizione |
|---|---|
| dns-lookup.txt | Risoluzione DNS completa dell'host: record A, AAAA, PTR, MX, NS e TXT con i rispettivi TTL |
| whois-info.txt | Interrogazione WHOIS del dominio e dell'indirizzo IP: registrante, registrar, date di registrazione, name server |
| traceroute.txt | Traceroute verso il server con ogni hop intermedio, indirizzo IP e latenza — documenta il percorso di rete |
| reverse-ip-lookup.txt | Reverse IP lookup: elenco dei domini ospitati sullo stesso indirizzo IP del server |
FILE ACQUISITI
| Percorso | Descrizione |
|---|---|
| files/ | Directory contenente la copia binaria esatta di tutti i file scaricati dal server, con la stessa struttura di directory originale |
| metadata/ | Directory contenente un file JSON per ogni file acquisito, con: percorso originale sul server, dimensione in byte, data di modifica, permessi, proprietario, gruppo e i quattro hash crittografici (MD5, SHA-1, SHA-256, SHA-512) |
MARCA TEMPORALE
| File | Descrizione |
|---|---|
| freetsa-cacert.pem | Certificato CA di FreeTSA, necessario per la verifica indipendente della marca temporale con OpenSSL |
| tsr-verifica.txt | Risultato della verifica automatica della marca temporale eseguita dal software subito dopo l'emissione |
Cosa rende completa un'acquisizione FTP
| Elemento | Perché è necessario |
|---|---|
| Server snapshot pre-download | Prova lo stato del server prima del download: quali file e directory erano presenti, con quali dimensioni e date. Se un file viene modificato o eliminato durante l'acquisizione, la discrepanza risulta documentata. |
| Modalità binaria TYPE I | Il download in modalità binaria garantisce che nessun byte venga alterato. In modalità ASCII (TYPE A), i fine riga vengono convertiti tra CRLF e LF, modificando il contenuto del file e invalidando gli hash. |
| 4 algoritmi di hash per file | MD5, SHA-1, SHA-256 e SHA-512 vengono calcolati simultaneamente durante lo streaming dei dati. La ridondanza su quattro algoritmi rende praticamente impossibile una collisione e garantisce compatibilità con qualsiasi strumento di verifica. |
| Verifica di coerenza | Confronto automatico tra le dimensioni dei file registrate nello snapshot e quelle dei file effettivamente scaricati. Qualsiasi discrepanza viene segnalata, indicando una possibile modifica avvenuta durante l'acquisizione. |
| Risposte MLSD grezze | Le risposte raw del comando MLSD vengono salvate senza elaborazione. Questo prova esattamente ciò che il server ha restituito, eliminando qualsiasi dubbio su interpretazioni o manipolazioni lato client. |
| Fingerprint del server | Il software del server viene identificato analizzando il banner 220, le risposte ai comandi SYST, FEAT e STAT. Identifica ProFTPD, vsftpd, Pure-FTPd, FileZilla Server, Microsoft IIS FTP, OpenSSH e altri. |
| Log del protocollo | Ogni comando FTP inviato e ogni risposta ricevuta vengono registrati con timestamp a millisecondi. Documenta la sequenza esatta delle operazioni e permette di ricostruire l'intera sessione. |
| Analisi forense della rete | Risoluzione DNS completa (A, AAAA, PTR, MX, NS, TXT), interrogazione WHOIS, traceroute, latenza TCP sulle porte 21, 22, 80 e 443 e reverse IP lookup. Documenta l'infrastruttura del server al momento dell'acquisizione. |
Domande frequenti
Acquisisci server FTP con valore legale
Scarica C.E.R.T.O. Desktop 3.1 e inizia subito le tue acquisizioni forensi FTP, FTPS e SFTP con hash, snapshot del server, log del protocollo e marca temporale.
Registrati gratis Vedi i prezzi