Fondamenti di Test di Sicurezza Etico con Python: Una Guida Pratica per Principianti
Capitolo 11 di 11 · aggiornato 08 lug 2026
Risoluzione dei problemi e insidie comuni: quando i laboratori si bloccano e gli script falliscono
Risoluzione dei problemi e insidie comuni: quando i laboratori si rompono e gli script falliscono
Il Lab Wintermute si romperà. Non potrebbe—si romperà. Ogni studente che abbia mai costruito un ambiente isolato per pentesting ha visto Kali perdere la sua scheda di rete dopo un aggiornamento del kernel, o ha visto il banner FTP di Metasploitable2 scomparire a metà esercizio, o ha eseguito uno script Python di ricognizione contro 192.0.2.20 solo per fissare un traceback che non significa nulla. Questa pagina è il runbook che avrei voluto avere durante le mie prime dozzine di costruzioni di laboratorio. Ogni blocco segue lo stesso ritmo: sintomo, diagnostica, soluzione, e cosa ho imparato a mie spese.
Sintomo: python avvia Python 2, python3 avvia 3.x, e i tuoi script falliscono con errori di sintassi print o attributi urllib mancanti
Probabile causa: Il sistema ha sia Python 2 che Python 3 installati, e la tua riga shebang, ambiente virtuale, o memoria muscolare punta all'interprete sbagliato. Questo è particolarmente comune su Kali Linux, che storicamente ha creato un symlink python a Python 2 per compatibilità con strumenti legacy.
Diagnostica:
which python && python --version
which python3 && python3 --version
ls -la /usr/bin/python*
Soluzione: Sii esplicito. In ogni intestazione di script, usa #!/usr/bin/env python3. Quando installi pacchetti, usa pip3 piuttosto che pip a meno che tu non abbia verificato quale interprete serva pip. Se hai creato un ambiente virtuale (un'installazione Python autonoma per l'isolamento del progetto), attivalo con source venv/bin/activate e verifica il percorso:
which python
# output illustrativo — verifica sul tuo target: /home/student/lab-wintermute/venv/bin/python
Perché questo è importante: Un ambiente virtuale copia l'interprete Python nella directory del tuo progetto. Quando attivato, si antepone al tuo
PATH. Questo previene conflitti di pacchetti a livello di sistema, ma solo se lo attivi effettivamente. Ho perso ore con script che giravano contro il Python di sistema mentre la mia libreriarequestsera installata in un venv inattivo.
Se vedi ModuleNotFoundError nonostante l'installazione del pacchetto, l'hai quasi certamente installato per l'interprete sbagliato. Disinstalla da quello sbagliato, reinstalla da quello giusto, e vai avanti.
Sintomo: pip install fallisce con errori di certificato SSL, timeout di connessione, o avvisi "externally-managed environment"
Probabile causa: I pacchetti Python gestiti da apt di Kali a volte confliggono con installazioni pip. Problemi di rete in un laboratorio isolato con NAT possono anche bloccare PyPI (il Python Package Index, il repository predefinito per le librerie Python). L'errore "externally-managed" si verifica sui sistemi più recenti che rifiutano di lasciare che pip inquini il Python di sistema.
Diagnostica:
pip3 --version
# Controlla prima se sei in un venv:
echo $VIRTUAL_ENV
# Testa la connettività a PyPI:
curl -I https://pypi.org/simple/requests/
# Controlla i log della gestione pacchetti di Kali per conflitti:
sudo tail -n 20 /var/log/apt/term.log
Soluzione: All'interno di un ambiente virtuale, pip dovrebbe funzionare liberamente. Se devi installare a livello di sistema su Kali, preferisci sudo apt install python3-<package> quando Kali lo fornisce. Per installazioni pure pip, usa il flag --user o un venv. Quando appaiono errori SSL in laboratori isolati, la causa è solitamente un captive portal o proxy di cui ti sei dimenticato, non un vero attacco ai certificati. Verifica prima la modalità di rete della tua VM (vedi blocco successivo).
Sintomo: la VM Kali può raggiungere internet ma non può fare ping a 192.0.2.20 o 192.0.2.30; o viceversa, raggiunge i target del lab ma perde dati verso la rete esterna
Probabile causa: Errata configurazione della scheda di rete di VirtualBox. Le quattro modalità che contano per il Lab Wintermute sono NAT (Kali raggiunge l'esterno attraverso l'host), Host-Only (le VM comunicano solo tra loro e con l'host), Internal Network (le VM comunicano tra loro, l'host è escluso), e Bridged (la VM appare come dispositivo fisico sulla tua rete reale—pericoloso per i laboratori di pentesting).
Diagnostica:
# Su Kali:
ip addr show
ip route show
ping -c 3 192.0.2.20
# Sull'host, controlla le impostazioni di rete di VirtualBox:
# VM Settings → Network → Adapter 1/2/3 → Attached to:
Soluzione: Per il requisito di isolamento air-gapped del Lab Wintermute, usa la modalità Internal Network per la subnet del lab. Kali necessita di una seconda scheda in modalità NAT se vuoi scaricare pacchetti durante la configurazione, ma disabilitala o mettila sotto firewall prima di eseguire qualsiasi scansione. Configuro Kali con Scheda 1: NAT (per aggiornamenti), Scheda 2: Internal Network "wintermute-lab" (per i target). Poi verifico l'isolamento:
# Verifica nessuna route verso la rete reale:
ip route | grep default
# Dovrebbe mostrare solo il gateway della scheda NAT, non una route attraverso Internal
# output illustrativo — verifica sul tuo target:
# default via 10.0.2.2 dev eth0
Perché questo è importante: La modalità Bridged ha causato una volta che la scansione
nmapdi uno studente colpisse la stampante del suo coinquilino. La scansione era innocua, ma il reparto IT del coinquilino non fu divertito. La modalità Internal Network è la tua rete di sicurezza legale.
Se i target sono irraggiungibili nonostante la modalità corretta, controlla conflitti IP. L'Internal Network di VirtualBox non esegue DHCP per impostazione predefinita. Assegna IP statici come stabilito nella fase di costruzione, o esegui un piccolo server DHCP su Kali se necessario.
Sintomo: i servizi Metasploitable2 appaiono down; nmap non mostra porte aperte su 192.0.2.20
Probabile causa: La VM target si è spostata dal suo IP statico, i servizi non sono partiti all'avvio, o la VM è stata ripristinata a uno snapshot corrotto.
Diagnostica:
# Da Kali:
nmap -sn 192.0.2.0/24
# Controlla se Metasploitable2 è vivo:
arp -a | grep 192.0.2.20
# Sulla console di Metasploitable2 (VirtualBox → Show):
ifconfig
# Controlla lo stato dei servizi per porte comuni:
netstat -tlnp | grep -E '21|22|23|25|80|445|3306'
Soluzione: Se l'IP è cambiato, il lease DHCP è scaduto o la configurazione statica è stata persa. Reimpostala in /etc/network/interfaces o tramite la console. Se i servizi sono down, avviali manualmente—il vecchio sistema init di Metasploitable2 può essere capriccioso:
# Su Metasploitable2 (illustrativo — verifica i nomi dei servizi):
sudo service ssh start
sudo service vsftpd start
sudo service apache2 start
Intuizione acquisita: Il MySQL di Metasploitable2 a volte non si avvia se il disco virtuale è pieno per i log. Il comando
df -hsul target mostrerà questo. Tengo uno snapshot prisitino etichettato "CLEAN_POST_BOOT" e non lo sovrascrivo mai. Se un servizio non si avvia e lo spazio disco va bene, ripristino quel snapshot piuttosto che debuggare gli script init per un'ora. L'obiettivo di apprendimento è capire le vulnerabilità, non assistere un'installazione Ubuntu di dieci anni fa.
Sintomo: DVWA su 192.0.2.30 mostra "Database connection failed" o setup.php riporta configurazione mancante
Probabile causa: Il file config/config.inc.php di DVWA punta al host database sbagliato, credenziali errate, o il servizio MySQL/MariaDB non è in esecuzione. I componenti dello stack XAMPP o LAMP potrebbero non essere partiti.
Diagnostica:
# Sul server DVWA:
sudo systemctl status mysql || sudo service mysql status
# Controlla la configurazione DVWA:
grep -E 'db_(user|password|server)' /var/www/html/dvwa/config/config.inc.php
# Testa la connettività al database direttamente:
mysql -u dvwa -p -h 127.0.0.1 -e "SHOW DATABASES;"
Soluzione: La configurazione DVWA predefinita spesso usa root con password vuota per localhost. In un ambiente di lab, potresti averla modificata durante esercizi di hardening. Se le credenziali sono state modificate e dimenticate, controlla i tuoi appunti di lab o reimpostale tramite la console root MySQL. Assicurati che il database esista e che l'utente DVWA abbia i privilegi:
-- SQL illustrativo — verifica sul tuo target
CREATE DATABASE IF NOT EXISTS dvwa;
GRANT ALL ON dvwa.* TO 'dvwa'@'localhost' IDENTIFIED BY 'your_lab_password';
FLUSH PRIVILEGES;
Se XAMPP è la piattaforma, potrebbe essere necessario sudo /opt/lampp/lampp start. Controlla /var/log/apache2/error.log e il log degli errori MySQL per i dettagli.
Sintomo: lo script Python crasha con OSError o eccezioni socket; connessione rifiutata, timeout, o "name or service not known"
Probabile causa: La programmazione di rete in Python espone ogni livello di fallimento. Il modulo socket (l'interfaccia di Python alle Berkeley sockets API per la comunicazione di rete) solleva eccezioni che sono sottoclassi di OSError. Cause comuni: servizio target non in esecuzione (connessione rifiutata), firewall o partizione di rete (timeout), errore DNS o IP (non risolto).
Diagnostica:
# Testa la connettività fuori da Python prima:
nc -vz 192.0.2.20 21
# Controlla la risoluzione DNS se usi nomi host:
getent hosts metasploitable2.wintermute.lab
# In Python, cattura e ispeziona l'eccezione:
python3 -c "
import socket, errno
try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(5) s.connect(('192.0.2.20', 9999))
except OSError as e: print(f'Error number: {e.errno}') print(f'Error name: {errno.errorcode.get(e.errno, "UNKNOWN")}') print(f'Message: {e.strerror}')
"
Soluzione: Abbina il valore errno al problema effettivo. Il modulo errno di Python prende i nomi dalle intestazioni di sistema Linux. errno.EPERM (mappato a PermissionError) suggerisce una regola firewall o problema di capability. Una connessione rifiutata significa che la porta è chiusa o il servizio è down—verifica con nmap. I timeout suggeriscono problemi di routing o che il target è sopraffatto.
Perché questo è importante: Gli studenti spesso catturano
Exceptiongenerica e stampano "è fallito." L'attributoerrnoti dice se controllare il target, la rete, o i tuoi permessi.os.strerror()traduce il codice numerico in un messaggio umano. La lista completa dei simboli definiti è disponibile tramiteerrno.errorcode.keys()per riferimento.
Per problemi di encoding quando si ricevono dati di rete: Python 3 distingue bytes (binario grezzo) da str (testo Unicode). Il recv() del socket restituisce bytes. Decodifica esplicitamente con .decode('utf-8', errors='replace') piuttosto che assumere l'encoding del peer.
Sintomo: tentazione di scansionare "solo un" host esterno, o il documento di scope è vago sui confini di 192.0.2.0/24
Probabile causa: Fatica da lab, curiosità, o autorizzazione scritta male. Lo scope creep (espansione del test oltre i confini concordati) è il fallimento etico più comune nei tester junior.
Diagnostica: Pausa. Rileggi l'accordo di scope scritto. L'autorizzazione del Lab Wintermute copre solo 192.0.2.10 (Kali), 192.0.2.20 (Metasploitable2), e 192.0.2.30 (DVWA). Qualsiasi pacchetto che lasci la scheda Internal Network verso indirizzi esterni è non autorizzato.
Soluzione: Verifica l'isolamento prima di ogni sessione:
# Conferma nessuna route di default attraverso l'interfaccia lab:
ip route show | grep 192.0.2
# Dovrebbe mostrare solo route per la subnet locale, non un gateway di default
# Controlla connessioni attive durante le scansioni:
ss -tuln | grep -v 127.0.0.1 | grep -v 192.0.2
# Qualsiasi IP non-lab qui è un segnale di allarme
⚠️ Solo per uso autorizzato e difensivo.
Documenta il tuo scope nel report di lab. Se contatti accidentalmente un indirizzo esterno—magari perché la modalità Bridged di VirtualBox era rimasta abilitata—fermati immediatamente, preserva i log, e divulga al tuo istruttore. La divulgazione responsabile si applica anche agli errori.
Sintomo: il lab è "strano" dopo molteplici esercizi di exploit; il comportamento non corrisponde allo stato pulito; possibile compromissione persistente del target
Probabile causa: Hai dimenticato di ripristinare dallo snapshot. Metasploitable2 e DVWA accumulano cambiamenti: utenti creati, file modificati, servizi crashati, backdoor installate da dimostrazioni di exploit riuscite. La fase di "report di apprendimento" richiede una baseline nota-good.
Diagnostica:
# Sulle VM target, controlla cambiamenti inaspettati:
find /tmp -type f -mtime -1
last | head
# Confronta con le tue note di ricognizione iniziali dalla Pagina 5
Soluzione: L'albero decisionale è semplice. Se hai uno snapshot pulito e devi continuare gli esercizi: ripristinalo. Se hai raggiunto la fase di report e devi documentare "artefatti post-exploitazione" per l'apprendimento: preserva prima i log, poi ripristina. Se lo snapshot era corrotto o sovrascritto: ricostruisci la VM dall'immagine base.
Checklist pre-sessione (stampa e spunta):
- [ ] Schede di rete VirtualBox verificate: NAT per aggiornamenti, Internal per lab
- [ ]
ip addrdi Kali mostra il 192.0.2.10 atteso - [ ] I target rispondono al ping agli IP documentati
- [ ] Snapshot ripristinato a "CLEAN_POST_BOOT" o equivalente
- [ ] Documento di scope aperto e rivisto
- [ ] Firewall dell'host blocca traffico VM non intenzionale (se applicabile)
Ripristino post-sessione:
# Su Kali, preserva i log di sessione prima del ripristino dello snapshot:
mkdir -p ~/wintermute-reports/session-$(date +%Y%m%d)
cp -r ~/.bash_history ~/wintermute-reports/session-$(date +%Y%m%d)/
cp /var/log/syslog ~/wintermute-reports/session-$(date +%Y%m%d)/ 2>/dev/null
# Poi ripristina le VM target tramite VirtualBox snapshot manager
Intuizione acquisita: Ho una volta passato tre ore a debuggare un comportamento "strano" di Metasploitable2 che si è rivelato essere il mio stesso exploit vsftpd riuscito della settimana precedente, ancora residente. Lo snapshot che pensavo di aver ripristinato era in realtà uno snapshot post-exploitazione che avevo etichettato male. Ora uso timestamp e prefissi "CLEAN_" religiosamente. Una convenzione di denominazione degli snapshot è la sicurezza operativa per la propria memoria.
Quando i log sono preservati, analizzali piuttosto che eliminarli. I log di Kali in /var/log/syslog, /var/log/auth.log, e /var/log/kern.log mostrano cosa è effettivamente successo. Per fallimenti specifici degli strumenti, consulta man <tool> o controlla /usr/share/doc/<package> per la documentazione. Se lo strumento è di terze parti, segnala i problemi al suo GitHub o GitLab piuttosto che ai maintainer di Kali o Debian—questo canalizza correttamente il tuo sforzo e costruisce relazioni professionali.
In termini semplici: I lab si rompono perché sono sistemi complessi con molte parti in movimento. La soluzione è quasi mai magia—è una verifica metodica di rete, servizio, codice, e scope, in quest'ordine. Documenta tutto, usa gli snapshot religiosamente, e in caso di dubbio, ripristina pulito.