La domanda "che cosa devo studiare per diventare un ethical hacker" ha una risposta che nessun corso dà, perché non è un elenco di argomenti. È un ordine, e l'ordine è l'unica parte che conta.
Chi sbaglia l'ordine rimane fermo. E chi lo sbaglia in un modo specifico finisce in una situazione molto comune: sa usare tre tool, non sa come funzionano, e quando il tool fallisce non ha niente su cui appoggiarsi.
Questo articolo non è un percorso con le stelline. È la risposta alla domanda: che cosa deve essere vero, e in che ordine, alla fine del primo anno.
Una nota sul contenuto di questo articolo: qui si parla di come imparare il mestiere. Quando arrivi a farlo davvero, valgono le regole che abbiamo scritto nel Vademecum dell'hacker, e la prima è che servono sistemi su cui hai un'autorizzazione scritta. Imparare sui propri computer non richiede nessun permesso: questo è il punto da cui si comincia e non va trascurato.
La risposta in una riga, se hai fretta
Prima sistemi, poi programmazione, poi reti, poi sicurezza. Non il contrario. E la programmazione viene prima della sicurezza, anche se è la cosa che nessuno vuole sentire.
Il motivo è che la sicurezza è una specializzazione. Non si può capire perché una SQL injection è possibile senza sapere che cosa sia una query, e non si può capire perché una macchina è vulnerabile senza sapere come funziona la memoria di un processo. Chi impara il "pentest" prima della programmazione impara una serie di procedure, e le procedure si rompono alla prima cosa che non è quella prevista.
Fase 1: i sistemi, e perché vengono per primi
Questa fase è quella che quasi nessuno fa, ed è quella che distingue chi capisce da chi esegue script.
Non devi studiare architettura dei calcolatori come un corso. Devi capire tre cose, e puoi capirle in poche settimane se le cerchi davvero:
che cosa sono i processi e come il sistema operativo decide chi usa la CPU e la memoria;
che cosa è la memoria virtuale e perché due programmi non possono leggere la memoria l'uno dell'altro;
che cosa sono i permessi e come il sistema decide se un'operazione è consentita.
Il motivo per cui vengono prima è che sono la base di quasi ogni vulnerabilità che vedrai in un assessment. Il buffer overflow non è un mistero di rete: è un programma che scrive oltre lo spazio che gli è stato assegnato, e capisci perché è successo solo se sai come sono fatti i processi.
Una prova concreta per capire se hai capito: spiega perché un programma con un bug di overflow non può, da solo, leggere la memoria di un altro programma. Se la risposta ti viene senza titubare, la fase è fatta. Se ti sembra ovvio che "può leggere tutto", non è fatto.
Fase 2: la programmazione, e quale
Qui la scelta conta più di quanto sembri, e quasi tutti scelgono male.
Python è la scelta migliore per cominciare, e non perché sia il più potente. È la scelta migliore perché ti lascia fare cose vere in pochissime righe, e una cosa vera fatta oggi vale dieci esercizi sintattici. I dettagli di perché è adatto al lavoro offensive li ho scritti in Python per l'ethical hacking.
Ma c'è una cosa che va detta perché quasi nessuno la dice: impara un secondo linguaggio con un tipo statico, e imparalo abbastanza da capire la differenza. Non per diventare produttivi in C. Per capire che cos'è un buffer e perché esiste.
Il motivo è che il salto da Python a C è il salto che rende leggibile il lato sicuro del mestiere. Chi ha capito perché in C un array non controlla i propri limiti capisce un buffer overflow davvero. Chi ha fatto solo Python usa la funzione di copia ma non sa perché è pericolosa, e questo si vede nel momento in cui lo strumento automatico sbaglia.
Un solo requisito pratico: impara abbastanza da leggere il codice degli altri. Non da scrivere un sistema operativo. Da leggere.
Fase 3: leggere il codice altrui, che è la vera competenza
Questa è la fase che nessun corso mette, ed è quella che ti rende indipendente. Se te la salti, resti legato a quello che i tool fanno.
Il metodo è semplice e scomodo: prendi un progetto piccolo e leggilo tutto. Non in modo tutorial, non "saltando le parti difficili". Tutto.
Un progetto di riferimento che gira sul tuo sistema e ha una
documentazione onesta è un buon primo candidato: sono più grandi di un
tutorial e più piccoli di un sistema operativo. In C, per esempio, una
shell come dash o un tool di rete come un resolver DNS: sono leggibili
in qualche serata e ti mostrano come è fatto davvero un programma che
parla con altri.
Mentre leggi, tieni una sola domanda in testa: "che cosa succede se questo valore non è quello che credo?". È la domanda dell'errore di input, e porta dritti alla maggior parte delle falle.
C'è anche un secondo, più veloce, per far prima: le issue pubbliche. Un progetto con duemila stelle ha una issue per ogni discussione fatta. Leggere le issue più accese del primo anno vale più di qualunque tutorial, perché li leggi come farebbe il maintainer: "qui qualcuno ha detto che funziona, ma se l'input è nullo succede altro".
Fase 4: le reti, e il punto in cui diventa utile
Le reti le abbiamo descritte nel dettaglio nell'articolo sulle disposizioni a strati, e non ripeto qui la teoria. Quello che dico è quando arrivarci.
Dopo che hai capito i processi e hai scritto qualche riga di codice che gira. Non prima, e non dopo.
Il motivo è che le reti da sole si imparano a memoria: sai che la porta 443 è HTTPS, e non sai perché una connessione a un servizio possa riuscire senza che nessuno abbia aperto niente. È la differenza fra sapere e capire, ed è la stessa che conta in ogni fase.
E a questo punto arriva il punto di svolta del percorso, che è uno solo e va detto bene: impara il mestiere da chi lo fa, guardando il lavoro vero. Un assessment reale, con le sue parti noiose, vale più di un laboratorio.
Il laboratorio: l'errore da evitare è sceglierlo male
Qui c'è il consiglio che mi sento di dare più spesso, perché l'ho visto fare bene e male molte volte.
L'obiettivo di un laboratorio è capire come funziona una macchina, non imparare a usare un tool. Sono due cose diverse e l'ordine è tutto.
Un laboratorio utile ha le caratteristiche che seguono:
te lo costruisci tu, almeno in parte. Una macchina che hai assemblato capiscila davvero, perché non puoi renderla più facile di quanto è.
è esposta solo dove deve essere. Una macchina di laboratorio non ha motivo di esistere su Internet: sta sulla tua rete locale o in una macchina virtuale isolata, e questo non è un dettaglio di sicurezza ma di metodo.
non è "completa". Un laboratorio pensato per essere finito si finisce e non ti insegna niente. Nei migliori c'è una parte che non funziona come dovrebbe, e tu devi capire perché.
La peggior cosa che puoi fare, e che vedo fare ogni settimana, è
cominciare dagli strumenti automatici. Ti danno una macchina, lanci
sqlmap, e il risultato è che non sai perché ha funzionato. Il giorno
in cui il tool sbaglia — e sbaglia — non hai niente.
Quindi: prima manuale, poi automatica. Fai la cosa a mano una volta, capisci che cosa hai fatto, e solo dopo automatizza. Il contrario è imparare una procedura che non sai.
E non dimenticare la parte che nessuno mette: scrivi sempre che cosa hai trovato. Ogni volta che trovi qualcosa, anche su un sistema tuo, scrivi due righe di spiegazione. Ti costa un minuto e ti dà tre cose: capisci se hai capito, hai il materiale per un referto e fra un anno non dovrai ricordare che cosa avevi notato.
Le tre cose che quasi tutti sbagliano al primo
1. Cercare il corso invece di fare il lavoro. Un corso ti dà il vocabolario, non la competenza. Non è male — ti fa risparmiare il tempo di cercare cosa studiare — ma non è quello che ti rende bravo. Il tempo si spende facendo, e l'errore è uno strumento a finestre strette.
2. Voler andare avanti troppo presto. Il sintomo è l'ansia di "primavere" nell'argomento di oggi. È quasi sempre un segnale che non hai ancora capito quello di ieri. È la cosa migliore che possa capitare.
3. Credere che la competenza tecnica basti. È l'equivoco che il mestiere non è solo tecnico, ed è l'unico dei tre che ti costa caro. Puoi essere il miglior tecnico della stanza e non riuscire a ottenere un autorizzazione firmata, e allora non puoi fare il lavoro.
Il resto del mestiere — che cosa si scrive in un report, come si parla con un cliente che ha ricevuto una notizia sgradita, che cosa fare quando trovi qualcosa che non avresti dovuto trovare — è la parte difficile, e non si impara da un tutorial.
Che cosa serve davvero, in ordine
La sintesi pratica, se vuoi la versione corta.
Primo mese. Sistema operativo: processi, memoria, permessi. Bash quanto basta per muoversi. Un libro di architettura, uno qualsiasi. Installa Linux e vivi in un terminale.
Secondo trimestre. Programmazione. Python per costruire, e un linguaggio statico per capire. Primi programmi che fanno qualcosa di vero: uno script, un parser, un client di rete.
Terzo trimestre. Reti, con la teoria fatta bene. E il primo laboratorio, costruito da te, con l'obiettivo di capire come funziona.
Primo anno. Leggere codice altrui di proposito. Il percorso del Vademecum, che è l'ordine con cui si guarda un sistema, e che adesso hai tutte le basi per capire. I primi tool, e il primo rapporto scritto per qualcuno.
Dopo. Questo non si mette in un programma. È tempo speso a fare assessment veri, con le persone che li fanno.
Che cosa è solo rumore
Meglio dirlo, perché è metà di quello che si trova online.
I corsi che promettono un lavoro in tre mesi. Nessuno vi dà un lavoro, e nessuno ve lo toglierà. Il certificato non fa parte del mestiere.
Le certificazioni come obiettivo. Servono per il curriculum in alcune organizzazioni e per nient'altro. Nessuno vi assume perché avete un esame.
Gli strumenti prima delle basi. Un tool che non capite non vi rende bravi, vi rende dipendenti da quello che oggi funziona.
Le liste di "skill richiesti" dei portali di lavoro. Sono generate, copiate e non descrivono nessun lavoro reale. Quelle che contano sono cinque: leggere, capire il sistema, scrivere, saper comunicare, e la parte etica che viene per prima.
La regola che usiamo noi
Il ragionamento di CYBER ONIONS su questo tema è una frase sola, e la ripetiamo a chi ci scrive:
Non imparare a usare gli strumenti per la sicurezza. Impara a capire i sistemi: gli strumenti cambiano ogni anno, e se sai perché funzionano non hai bisogno di reimpare nulla.
Il percorso è lento, e questa è la parte difficile. Ma alla fine del primo anno non hai un insieme di procedure memorizzate: hai la capacità di guardare una macchina sconosciuta e capire dove comincia a rompersi. Il giorno in cui arrivi a quel punto, il mestiere è già tuo.
Se di tutto questo resta una cosa sola: costruisci il laboratorio e provalo a mano, prima di automatizzare. Tutto il resto è contorno.