Facile on u-random

Il CEO Non Ha Scritto Quella Email

Tue, 19 May 2026 00:00:00 +0000

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.

Tutti Potevano Leggere Tutto

Tue, 19 May 2026 00:00:00 +0000

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.

La Lettera che Cambia Busta

Thu, 02 Apr 2026 00:00:00 +0000

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

Cosa succede davvero sulla rete mentre il tuo codice gira

Tue, 31 Mar 2026 00:00:00 +0000

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] & 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?

Offline. Non al buio.

Thu, 26 Mar 2026 00:00:00 +0000

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

Anatomia di una query DNS

Mon, 23 Mar 2026 00:00:00 +0000

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.

Il file che si comporta da root - capire il bit SUID

Mon, 23 Mar 2026 00:00:00 +0000

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>/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.

Chi Sei per il Kernel

Wed, 18 Mar 2026 00:00:00 +0000

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>/dev/null
chmod u+s /path/to/file
chmod u-s /path/to/file
find / -perm -4000 -type f 2>/dev/null | grep -v -E "^/(usr/bin|usr/sbin|bin|sbin|usr/lib)"

Linux non sa chi sei. Sa solo il tuo numero.