Rocco Sicilia

E’ il primo post di questa serie che, ad essere sinceri, sostituisce una sedie di post che avevo iniziato con riferimento ad una specifica certificazione. Cambio modello per diverse ragioni ed inizio dal lab che ho predisposto per lo studio.

Nulla di complesso: per ragioni pratiche ho optato per una macchina d’appoggio con installato VirtualBox su cui ho predisposto quattro VMs:

• Una VM Kali, necessaria per diverse certificazioni in ambito PenTesting
• Una VM Windows Server 2019, utile sia a livello di OS che per i servizi Active Directory che meritano un approfondimento
• Una VM Windows 10 Pro, classico ambiente desktop joined al dominio Active Directory
• Una VM Ubuntu Server LTS, macchina d’appoggio linux che è sempre comodo avere a disposizione

Con un po’ di tuning a livello di risorse non dovrebbe essere un problema far girare le quattro VMs contemporaneamente: nel mio caso l’host mette a disposizione un processore i5 2.90 GHz x4 core e 8 GB di RAM; a VM accese sono utilizzate per il 40% le CPU e per il 90% la RAM. Sul piano dei costi un mini-pc che metta a disposizione queste prestazioni ha un costo variabile tra i 200 e i 400 € e ha un consumo, in carico, di circa 60W-70W.

[Nota sui consumi] Considerando un utilizzo medio di 8 ore al giorni della macchina “server” va calcolato un consumo di circa 0,5 kWh al giorni pari a circa 10 cent. di € al giorno (dati di luglio 2023 in Italia). Considerando un utilizzo intenso giornaliero per sei mesi di studio, l’investimento in termini di consumo elettrico per il solo lab personale è di 90 € circa.

Per una questione di mio personale ordine mentale preferisco configurare una rete separata per le macchine di laboratorio dietro NAT. Su VirtualBox si può ottenere facilmente creando una nuova NatNetwork: nel mio caso la rete selezionata è la 10.0.2.0/24 con DHCP rilasciato direttamente dal software di virtualizzazione. Per raggiungere gli ambienti dalla mia Workstation (un MacBook) configurerò dei NAT specifici, per iniziare sono sufficienti i NAT per SSH delle due macchina linux e RDP per le due macchina Windows.

Rispetto alla configurazione che si potrebbe ottenere con un ESXi ed un piccolo Firewall, utilizzare i NAT in un ambiente host è sicuramente più scomodo e limitato in quanto è necessario condividere l’IP della macchina host tra i vari servizi, cosa che richiede l’utilizzo di porte non standard. Ad esempio il NAT per la 3389 della macchina Win2019-DC è costruito sulla porta 13389 dell’host mentre lo stesso NAT per la macchina Win10 utilizza la porta 23389 dell’host. Un gioco simile va fatto per i servizi SSH delle macchine linux.

Come client per connettersi ai sistemi è sufficiente un client RDP ed un client SSH. Due software molto versatili sono mRemote-ng e Remote Desktop Manager (quest’ultimo disponibile anche per Linux e OSX). Sul fronte dei terminal client, ci sono diversi tools con funzionalità interessanti, tra i vari cito Termius. Spazio nei commenti se qualcuno vuole citare client che utilizza abitualmente, ho pensato di citare i software che utilizzo per agevolare eventuali neofiti.

Il ruolo delle macchine

Molte certificazioni in ambito offensivo richiedono l’utilizzo di un sistem di “attacco” e di sistemi da attaccare, di solito definiti target o “vittima”. Il lab così configurato ci mette a disposizione la macchina Kali come sistema di attacco ricco di tools e come target tre sistemi che saranno utili per esercitarsi in diversi contesti. Servirebbe anche qualcosa sulla parte network ma su questo punto eventualmente valuterò l’introduzione di qualche virtual appliance.

Il mondo Microsoft in generale è un ambito d’azione abbastanza tipico: molti ambienti Server e Desktop nelle organizzazioni utilizzano sistemi operativi Microsoft più o meno recenti e uno dei servizi più utilizzati nelle aziende è Active Directory, ha quindi perfettamente senso configurare il sistema server come Domain Controller ed eseguire la join a dominio del sistema client (qui trovate un tutorial passo-passo per configurare un dominio Active Directory).

Approfondire il funzionamento di AD vi sarà molto utile: il percorsi di certificazione lo trattano, giustamente, in modo superficiale spiegando le funzioni base ma una comprensione profonda della struttura AD e delle sue peculiarità vi darà modo di eseguire assessment e penetration test molto accurati e profondi. Negli ultimi anni l’attenzione verso la sicurezza di Active Directory è cresciuta molto ed è diventato un punto fondamentale dei controlli di sicurezza, nell’ultimo anno ho seguito diverse verifica di queste strutture sia a livello di assessment che a livello di pen testing. Vi lascio il link ad una play list molto utile allo scopo di John Hammond.

Anche Linux è ampiamente utilizzato soprattutto in contesti server: web server, application server, servizi di rete, sono tantissime le soluzioni che utilizzano una distrubuzione linux come base e questo sistema operativo è molto utilizzanto anche in appliance e device di qualsiasi dimensione, dalle controller di uno storage al sistema operativo dei distributori automatici di bevande.

Avrebbe senso prendere in considerazione anche altri sistemi operativi come Mac OSX visto che è molto utilizzato dagli utenti, ma non è in scope per il percorso che sto portando avanti. Ciò non toglie che, avendolo come postazione di lavoro, spenderemo del tempo per fare qualche approfondimento.

Predisposizione della macchina Kali

Accedere al sistema Kali, una volta installato, è semplicissimo: sarà sufficiente avviare il servizio SSH dalla console della macchina e poi utilizzare il client SSH che avete scelto per connettersi al sistema:

Per abitudine creso spesso due directory sui miei sistemi di test: Coding, in cui mettere eventuale codice scritto durante le sessioni di studio, e Labz, per raccogliere eventuali dati sui laboratori. Nei prossimo post utilizzero questa struttura.

E’ ovviamente necessario assicurarsi che la macchina sia in grado di dialogare con il sistema target attraverso la rete virtuale appositamente creata. Essendo tutti i sistemi nello stesso dominio di broadcast potremo fare una verifica eseguendo un ping verso gli altri sistemi e utilizzando il comando arp -n per ottenere l’arp table della macchina e gli host noti a livello 2:

In contesti reali la configurazione a livello di rete è solitamente (si spera) un po’ più articolata: sistemi server e sistemi client non sono posizionati nello stesso segmento di rete ed esistono delle policies di gestione del traffico tra utenti e servizi. Durante le attività operativi il contesto deve essere tenuto in considerazione ed è uno degli elementi di analisi.

Anticipazioni

Nei prossimi post vorrei esporre i temi di studio basandomi su esercizi in lab. e materiale di approfondimento. I post saranno sempre pubblici mentre la parte di approfondimento la metterò a disposizione tramite video su Patreon dove potremo anche discutere con la community.

Primo argomento tecnico: Information Gatherting.

Update del 27.04.2024 su patreon: https://www.patreon.com/posts/103141245.