Teoria on u-random

Le Autostrade di Internet

Wed, 22 Apr 2026 00:00:00 +0000

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"

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.

Il lucchetto verde - cosa succede davvero in quei 250 millisecondi

Sun, 22 Mar 2026 00:00:00 +0000

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>/dev/null | openssl x509 -noout -dates
openssl s_client -connect google.com:443 </dev/null 2>/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.