{"id":2202,"date":"2025-08-21T16:54:57","date_gmt":"2025-08-21T14:54:57","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=2202"},"modified":"2025-10-11T12:16:25","modified_gmt":"2025-10-11T10:16:25","slug":"fond-inform-reti-calc-sic-inform","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/08\/21\/fond-inform-reti-calc-sic-inform\/","title":{"rendered":"Fondamenti di informatica e reti di calcolatori per la sicurezza informatica"},"content":{"rendered":"\n<p class=\"has-medium-font-size\"><strong>Introduzione<\/strong><\/p>\n\n\n\n<p>Il presente articolo vuole fornire una panoramica strutturata dei fondamenti di informatica e reti di calcolatori, con un focus sull\u2019applicazione pratica di tali conoscenze nel contesto della <strong>sicurezza informatica<\/strong>. Ciascuna sezione approfondisce un argomento chiave \u2013 dalla rappresentazione dei dati ai sistemi operativi, dalle basi di dati alle reti e protocolli \u2013 evidenziando i concetti teorici essenziali e collegandoli alle best practice per la prevenzione e gestione di incidenti informatici.<\/p>\n\n\n\n<p>La trattazione \u00e8 pensata per il responsabile della sicurezza informatica impegnato nella <em>prevenzione e gestione di incidenti informatici<\/em>.<\/p>\n\n\n\n<p>Vengono inclusi esempi pratici, riferimenti a standard riconosciuti e citazioni da fonti autorevoli, il tutto organizzato in sezioni chiare per facilitare la consultazione e l\u2019apprendimento.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-b7be961feb73df596938d309a67b2ae6\"><strong>Rappresentazione delle informazioni<\/strong><\/p>\n\n\n\n<p>Nella scienza dei calcolatori, rappresentare le informazioni significa tradurre qualsiasi tipo di dato (numeri, testo, immagini, audio, ecc.) in una forma binaria comprensibile e manipolabile dalle macchine digitali. In pratica, ogni informazione viene codificata come sequenze di <strong>bit <\/strong>(binary digits), ossia 0 e 1, che sono le unit\u00e0 elementari di dati. Un insieme di 8 bit forma un <strong>byte<\/strong>, che costituisce la minima unit\u00e0 indirizzabile di memoria. Usando sequenze di bit e byte, un computer pu\u00f2 rappresentare qualsiasi tipo di contenuto: caratteri testuali, valori numerici, immagini, suoni, video, ecc. La conversione dei dati in sequenze di 0 e 1 prende il nome di codifica e risponde al requisito fondamentale per cui <strong>un computer elabora solo informazioni in formato binario<\/strong>.<\/p>\n\n\n\n<p><strong>Unit\u00e0 di misura e codifiche<\/strong>: poich\u00e9 i bit da soli sarebbero poco maneggevoli, si utilizzano multipli come Kilobyte (KB), Megabyte (MB), Gigabyte (GB), tenendo presente che in informatica per ragioni storiche spesso 1 KB = 1024 byte (2^10) invece di 1000 (si parla pi\u00f9 precisamente di Kibibyte). Sul versante delle codifiche, per rappresentare testi alfanumerici si impiegano sistemi standardizzati di mappatura tra numeri e caratteri. Uno dei pi\u00f9 importanti \u00e8 il codice <strong>ASCII<\/strong>, che associa a ogni simbolo (lettera, cifra, segno di punteggiatura, caratteri di controllo, ecc.) un valore numerico tra 0 e 127, rappresentabile con 7 bit. Ad esempio, il carattere &#8216;A&#8217; in ASCII \u00e8 codificato come 65 (in decimale), mentre &#8216;a&#8217; \u00e8 97 e cos\u00ec via. Estensioni di ASCII utilizzano 8 bit (256 valori possibili) per supportare caratteri accentati e simboli aggiuntivi, sebbene queste estensioni non fossero unificate a livello internazionale. Oggi si utilizza ampiamente <strong>Unicode<\/strong>, un sistema di codifica che, nelle sue varianti come UTF-8 e UTF-16, pu\u00f2 rappresentare decine di migliaia di caratteri (oltre i caratteri latini, anche alfabeti non latini, ideogrammi, emoji, ecc.). Unicode in UTF-8 \u00e8 retro-compatibile con ASCII per i primi 128 valori e consente di codificare caratteri usando sequenze di 1-4 byte. Grazie a Unicode, applicazioni e sistemi possono gestire testi multilingue e simboli emoji in modo unificato.<\/p>\n\n\n\n<p><strong>Numeri e formati numerici<\/strong>: i numeri interi vengono rappresentati in binario utilizzando un certo numero di bit fissato (es. 32 bit o 64 bit). Per i numeri <strong>con segno<\/strong> (positivi\/negativi) l\u2019approccio pi\u00f9 diffuso \u00e8 la rappresentazione in complemento a due, in cui il bit pi\u00f9 significativo indica il segno e l\u2019operazione di inversione dei bit pi\u00f9 aggiunta di 1 permette di ottenere il negativo di un valore.<br>Il complemento a due \u00e8 lo schema standard adottato nei moderni calcolatori per i numeri interi con segno, poich\u00e9 facilita la progettazione dei circuiti aritmetici (addizione e sottrazione possono essere eseguite con lo stesso circuito sommatorio). Ad esempio, con 8 bit si possono rappresentare gli interi da -128 a +127 in complemento a due. Per i <strong>numeri reali<\/strong> (con virgola decimale), si utilizza la rappresentazione in virgola mobile secondo lo standard IEEE 754, che definisce formati a 32 bit (precisione singola) e 64 bit (precisione doppia), tra gli altri. Questo standard specifica come suddividere i bit di un numero reale in segno, esponente e mantissa, permettendo di rappresentare un ampio intervallo di valori (inclusi zero, infiniti e valori NaN per indicare risultati non numerici). La conformit\u00e0 allo standard IEEE 754 garantisce che diversi processori e linguaggi interpretino i numeri in virgola mobile nello stesso modo, importante per la consistenza dei calcoli (ad esempio in crittografia o analisi scientifiche).<\/p>\n\n\n\n<p><strong>Rappresentazione di immagini, audio e altri dati<\/strong>: oltre a testo e numeri, i computer rappresentano anche dati multimediali in forma binaria. Un\u2019<strong>immagine digitale<\/strong> ad esempio \u00e8 modellata come una griglia di elementi chiamati pixel, ciascuno associato a valori binari che ne determinano il colore. In una immagine raster (bitmap), ogni pixel ha componenti di colore (ad esempio rosso, verde, blu in RGB) codificate tipicamente su 8 bit ciascuna, per un totale di 24 bit per pixel (True Color). Ci\u00f2 significa che un singolo pixel pu\u00f2 assumere circa 16,7 milioni di combinazioni di colore. Immagini con palette pi\u00f9 ridotte possono usare meno bit per pixel (ad esempio 8 bit\/pixel in modalit\u00e0 256 colori). Allo stesso modo, un\u2019immagine in bianco e nero pu\u00f2 essere codificata con 1 bit per pixel (0 = bianco, 1 = nero), eventualmente con livelli di grigio se si usano pi\u00f9 bit. Per i <strong>suoni<\/strong>, la rappresentazione avviene mediante campionamento: l\u2019onda sonora analogica viene misurata (campionata) a intervalli regolari e ogni campione viene quantizzato in formato digitale (ad esempio, audio CD utilizza 44.100 campioni al secondo, ciascuno rappresentato da 16 bit per canale). Il risultato \u00e8 una sequenza binaria che descrive l\u2019andamento dell\u2019audio nel tempo. Video e altri tipi di dati sono combinazioni o estensioni di questi principi (sequenze di immagini per il video, eventualmente compresse; flussi di campioni audio, ecc.), sempre riconducibili a stringhe di bit.<\/p>\n\n\n\n<p><strong>Implicazioni per la sicurezza informatica<\/strong>: la corretta comprensione della rappresentazione dei dati \u00e8 fondamentale nella sicurezza informatica per diversi motivi. In primo luogo, molte vulnerabilit\u00e0 di basso livello (come buffer overflow o integer overflow) derivano da limiti nella rappresentazione binaria: ad esempio un intero a 32 bit ha un massimo e se un calcolo eccede quel massimo si verifica un overflow con possibili esiti imprevisti. Conoscere come i numeri sono codificati (complemento a due, IEEE 754 per i float, ecc.) aiuta a prevenire errori di programmazione sfruttabili da attaccanti. Inoltre, la rappresentazione binaria \u00e8 alla base della <strong>crittografia<\/strong>: bit e byte vengono manipolati con operazioni booleane e aritmetiche per cifrare\/decifrare informazioni. Un esperto di sicurezza deve conoscere, ad esempio, come lavorano gli algoritmi bit-a-bit e come interpretare dumps binari o esadecimali di file e pacchetti di rete durante un\u2019analisi forense. Anche l\u2019<strong>encoding <\/strong>dei caratteri \u00e8 rilevante: attacchi come Unicode spoofing (ingannare sistemi di autenticazione usando caratteri Unicode simili a quelli latini) o bypass di filtri basati su codifiche differenti (ad esempio doppia codifica in attacchi XSS) sfruttano dettagli della rappresentazione dei testi. Infine, la capacit\u00e0 di tradurre rapidamente dati binari in forme comprensibili (come visualizzare un file eseguibile in esadecimale, o un indirizzo IP nella notazione dotted-decimal) \u00e8 una competenza pratica quotidiana per chi gestisce incidenti: consente di identificare payload malevoli nascosti, firme di file e altri indicatori di compromissione.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-db3925288e6646724bf66362267b6b6c\"><strong>Architettura degli elaboratori<\/strong><\/p>\n\n\n\n<p>Un <strong>elaboratore (computer)<\/strong> moderno si basa sul modello concettuale di architettura di von Neumann, che prevede la suddivisione in componenti fondamentali: una <strong>Unit\u00e0 Centrale di Elaborazione (CPU)<\/strong>, una <strong>memoria centrale<\/strong>, dispositivi di <strong>input\/output (I\/O)<\/strong> e interconnessioni dette <strong>bus<\/strong>. In tale architettura, sia i dati che le istruzioni di un programma sono memorizzati nella medesima memoria e la CPU li preleva ed esegue sequenzialmente. Di seguito esaminiamo ciascun componente e le implicazioni relative alla sicurezza.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CPU (Central Processing Unit)<\/strong>: \u00e8 il \u201ccervello\u201d del computer, responsabile dell\u2019esecuzione delle istruzioni macchina. La CPU \u00e8 internamente composta da un\u2019<strong>unit\u00e0 di controllo (Control Unit, CU)<\/strong> che dirige l\u2019esecuzione delle istruzioni, da un\u2019<strong>unit\u00e0 aritmetico-logica (ALU)<\/strong> che effettua calcoli e operazioni logiche e da una serie di registri interni per l\u2019immagazzinamento temporaneo di dati e indirizzi. La CPU esegue le istruzioni in un ciclo di <em>fetch-decode-execute<\/em>: preleva un\u2019istruzione dalla memoria, la decodifica e la esegue, aggiornando eventualmente registri e memoria. Le istruzioni stesse costituiscono il cosiddetto <strong>linguaggio macchina<\/strong> specifico della famiglia di CPU in uso (ad esempio x86-64, ARMv8, etc.). La maggior parte delle CPU moderne supporta funzionalit\u00e0 come <em>pipeling <\/em>(esecuzione parallela sovrapposta di parti di istruzioni diverse) e <em>multithreading <\/em>(gestione di pi\u00f9 flussi di istruzioni) per migliorare le prestazioni. Dal punto di vista della sicurezza, la CPU implementa meccanismi hardware essenziali, come i <strong>livelli di privilegio<\/strong> (es. modalit\u00e0 <strong>kernel <\/strong>vs <strong>user<\/strong>): le moderne CPU possono operare in almeno due modalit\u00e0, in cui le istruzioni cosiddette <em>privilegiate <\/em>(che accedono a risorse critiche o configurazioni hardware) possono essere eseguite solo in modalit\u00e0 kernel (dove risiede il sistema operativo), ma non in modalit\u00e0 utente. Questo isolamento hardware garantisce che un programma in esecuzione applicativa non possa, ad esempio, modificare direttamente la memoria del kernel o interagire col dispositivo disco senza passare per il sistema operativo \u2013 prevenendo una vasta gamma di abusi. Tuttavia, sono noti attacchi (<em>Meltdown, Spectre<\/em>) che sfruttano caratteristiche delle CPU (esecuzione speculativa, branch prediction) per aggirare tali protezioni, sottolineando come l\u2019architettura hardware sia anch\u2019essa un fronte di sicurezza da curare.<\/li>\n\n\n\n<li><strong>Memoria centrale<\/strong>: \u00e8 il luogo in cui risiedono i programmi in esecuzione e i dati su cui operano. La memoria centrale (di solito <strong>RAM<\/strong>, Random Access Memory, volatile) contiene sia le istruzioni macchina caricate dal disco sia le strutture dati necessarie alle applicazioni. La caratteristica \u00e8 l\u2019accesso diretto rapido agli indirizzi di memoria (a differenza delle memorie di massa pi\u00f9 lente). La memoria centrale memorizza sia i dati da elaborare (o gi\u00e0 elaborati) sia le istruzioni eseguibili. Tipicamente \u00e8 organizzata in una sequenza di celle indirizzabili (parole di memoria) tutte della stessa dimensione (es. 8 byte), ognuna identificata da un indirizzo numerico univoco. La memoria \u00e8 spesso distinta in <strong>RAM <\/strong>(lettura\/scrittura, volatile) e <strong>ROM\/EPROM<\/strong> (Read-Only Memory, memorie non volatili contenenti ad esempio il firmware di bootstrap). Un aspetto cruciale dell\u2019architettura \u00e8 la <strong>gerarchia di memoria<\/strong>: piccole memorie velocissime (registri nella CPU, cache L1\/L2\/L3) mitigano la differenza di velocit\u00e0 tra CPU e RAM; pi\u00f9 in basso vi sono memorie di massa (SSD, HDD) e archivi esterni. Ai fini della sicurezza, la gestione della memoria \u00e8 un terreno fertile di vulnerabilit\u00e0: <em>buffer overflow<\/em> (scrittura oltre i limiti di un buffer), <em>use-afterfree<\/em> (uso di memoria gi\u00e0 deallocata) e<em> memory corruption<\/em> in genere sono alla radice di exploit. Negli ultimi decenni, sono stati introdotti contromisure hardware come il bit NX (<em>No-eXecute<\/em>, che marca le pagine di memoria dati come non eseguibili per prevenire l\u2019iniezione di shellcode) e tecniche come <strong>ASLR<\/strong> (Address Space Layout Randomization, implementata a livello di sistema operativo ma dipendente dal supporto CPU per la segmentazione\/paginazione) per rendere pi\u00f9 difficile sfruttare i bug di memoria. Un responsabile alla sicurezza deve comprendere come funzionano queste protezioni hardware\/memory e i limiti che possono avere, per esempio sapere che buffer overflow su architetture moderne possono essere mitigati ma non eliminati (es. <em>return-oriented programming<\/em> \u00e8 nato proprio come tecnica per bypassare NX-bit e ASLR sfruttando frammenti di codice legittimo in memoria).<\/li>\n\n\n\n<li><strong>Bus e dispositivi I\/O<\/strong>: i vari componenti sono collegati da bus di sistema (insieme di linee di comunicazione). Esistono tipicamente bus separati o logici distinti per <strong>indirizzi, dati e controllo<\/strong>, che coordinano il flusso delle informazioni tra CPU, memoria e periferiche. Le <strong>periferiche di I\/O<\/strong> (dispositivi di input\/output come tastiera, mouse, schermo, disco, scheda di rete, ecc.) interagiscono col processore attraverso controller specifici collegati sul bus. Da una prospettiva di sicurezza, i dispositivi I\/O possono rappresentare vettori di attacco se non gestiti correttamente: ad esempio, dispositivi esterni USB possono iniettare comandi (si pensi a Rubber Ducky che si presenta come tastiera HID); le schede di rete possono essere bersaglio di <em>DMA attacks<\/em> (accesso diretto alla memoria) se l\u2019IOMMU non isola adeguatamente le periferiche. Inoltre, dal bus passano anche dati sensibili (ad esempio password digitate da tastiera o chiavi crittografiche in RAM) e attacchi di tipo side-channel hanno dimostrato che \u00e8 possibile captare informazioni sul bus o analizzare i tempi di risposta del sistema per dedurre segreti.<\/li>\n<\/ul>\n\n\n\n<p><strong>Set di istruzioni e architetture<\/strong>: ogni CPU implementa un <strong>Instruction Set Architecture (ISA)<\/strong>, l\u2019insieme di istruzioni macchina che \u00e8 in grado di eseguire. Architetture diverse (x86, ARM, MIPS, RISC-V, ecc.) hanno ISA differenti e anche modalit\u00e0 operative differenti (32-bit, 64-bit, little endian vs big endian nell\u2019ordinamento dei byte in memoria, ecc.). Nello sviluppo di exploit o nella risposta a incidenti, \u00e8 spesso necessario comprendere l\u2019architettura bersaglio: ad esempio, malware scritto per ARM non girer\u00e0 su un server x86 a meno di emulazione e viceversa. Inoltre, <strong>la sicurezza del software \u00e8 strettamente legata all\u2019architettura<\/strong>: un binario compilato per x86-64 con protezioni come <em>stack canaries<\/em> (canarini sullo stack) e <em>Control Flow Guard<\/em> sfrutta funzionalit\u00e0 specifiche dell\u2019ISA e del compilatore; un analista deve sapere come riconoscerle ed eventualmente disattivarle in ambiente controllato per effettuare reverse engineering. Parimenti, alcune istruzioni privilegiate (come la gestione della tabella delle pagine di memoria) sono sfruttate nei <em>rootkit<\/em> in modalit\u00e0 kernel: conoscere il funzionamento interno della MMU (Memory Management Unit) e delle istruzioni correlate pu\u00f2 aiutare a individuare manipolazioni malevole a basso livello.<\/p>\n\n\n\n<p>In sintesi, l\u2019architettura degli elaboratori fornisce il substrato hardware su cui operano i sistemi software. Un responsabile della sicurezza informatica deve padroneggiare almeno i concetti fondamentali (ciclo macchina, gestione memoria, modelli architetturali) per comprendere sia come prevenire incidenti (es. configurare correttamente protezioni hardware, scegliere architetture sicure per certi servizi critici) sia come analizzare incidenti avvenuti (es. dump di memoria, istruzioni eseguire da un malware, log di errori CPU come <em>kernel panic<\/em> o <em>machine check exception<\/em>). Inoltre, la cooperazione tra hardware e software in termini di sicurezza \u00e8 sancita da standard e best practice: ad esempio, l\u2019<strong>UEFI Secure Boot<\/strong> sfrutta funzionalit\u00e0 firmware\/hardware per garantire che all\u2019accensione vengano eseguiti solo bootloader firmati e tecnologie come <strong>TPM <\/strong>(Trusted Platform Module) offrono radici hardware di fiducia utilizzate dai sistemi operativi per funzionalit\u00e0 come BitLocker (crittografia disco) o l\u2019attestazione di integrit\u00e0. Tutti questi aspetti richiedono una conoscenza delle basi architetturali per essere implementati e gestiti con successo.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-d7fa80cd1aebb4b46392e9134cc0fa54\"><strong>Sistemi operativi<\/strong><\/p>\n\n\n\n<p>Un <strong>sistema operativo<\/strong> (SO) \u00e8 il software di base che funge da intermediario tra l\u2019hardware del computer e i programmi applicativi, gestendo le risorse del sistema e fornendo servizi essenziali agli utenti e alle applicazioni. In altre parole, il sistema operativo \u00e8 composto da vari <strong>componenti<\/strong> integrati (kernel, gestore dei processi, gestore della memoria, file system, driver di periferica, interfaccia utente, ecc.) che insieme assicurano il funzionamento coordinato del computer. Esempi comuni di sistemi operativi sono Windows, Linux, macOS per desktop\/server e Android, iOS per dispositivi mobili. Di seguito analizziamo le principali funzioni di un SO, evidenziando la loro importanza nella sicurezza informatica.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Gestione dei processi e multitasking<\/strong>: il sistema operativo consente di eseguire pi\u00f9 programmi in (pseudo)parallelismo attraverso la gestione dei <strong>processi<\/strong> e dei <strong>thread<\/strong>. Un <em>processo<\/em> \u00e8 un\u2019istanza in esecuzione di un programma, con un proprio spazio di indirizzamento in memoria, mentre un <em>thread<\/em> \u00e8 un flusso di esecuzione all\u2019interno di un processo (i thread di uno stesso processo condividono memoria e risorse). Il <strong>kernel<\/strong> (nocciolo del sistema operativo) include uno scheduler che assegna la CPU ai vari processi\/thread attivi, implementando politiche di scheduling (round-robin, priorit\u00e0, ecc.) per garantire reattivit\u00e0 e far avanzare tutti i carichi di lavoro. In ambito sicurezza, la corretta separazione dei processi \u00e8 cruciale: il sistema operativo deve isolare gli spazi di memoria in modo che un processo non possa leggere\/scrivere la memoria di un altro (violando la confidenzialit\u00e0 o integrit\u00e0). Ci\u00f2 \u00e8 realizzato tramite l\u2019<strong>MMU<\/strong> (unit\u00e0 di gestione memoria) e meccanismi come la traduzione di indirizzi (paginazione) che il SO controlla. Un attaccante spesso cerca di rompere questo isolamento (es. tramite <em>local privilege escalation exploits<\/em> che da un processo utente permettono di eseguire codice in contesto kernel). Pertanto, funzioni come il caricamento di moduli kernel firmati, l\u2019implementazione di <em>sandbox<\/em> (che confinano processi potenzialmente pericolosi in ambienti limitati) e la gestione attenta delle API di interprocess communication (pipe, socket, shared memory) sono aspetti di sicurezza legati alla gestione dei processi.<\/li>\n\n\n\n<li><strong>Gestione della memoria<\/strong>: il sistema operativo fornisce astrazioni di memoria ai processi, tipicamente sotto forma di <strong>memoria virtuale<\/strong>. Ogni processo vede uno spazio di indirizzi virtuali che il kernel mappa sulla memoria fisica reale, garantendo che processi diversi non interferiscano. Il <strong>gestore della memoria<\/strong> del SO si occupa di allocare e liberare memoria su richiesta dei programmi (tramite chiamate di sistema come <code>malloc\/free<\/code> in C, o automaticamente tramite garbage collector in linguaggi gestiti), di swappare porzioni di memoria su disco se la RAM scarseggia (memoria virtuale paginata) e di proteggere regioni critiche (ad esempio lo spazio di indirizzi del kernel \u00e8 reso non accessibile ai processi utente, solitamente). Tecniche come ASLR &#8211; Address Space Layout Randomization (randomizzazione dello spazio degli indirizzi) sono abilitate dal sistema operativo per rendere meno prevedibili gli indirizzi di librerie, stack e heap, mitigando gli exploit basati su buffer overflow. Il responsabile alla sicurezza deve conoscere queste tecniche e assicurarsi che siano abilitate (ad esempio, <strong>DEP\/NX<\/strong> e ASLR attivi, stack guard pages, ecc.), nonch\u00e9 essere in grado di analizzare <em>core dump<\/em> o tracce di crash per capire se un incidente \u00e8 dovuto a corruzione di memoria. Inoltre, la gestione della memoria comprende i permessi di accesso alle pagine (read\/write\/execute): un sistema operativo robusto segrega scrupolosamente codice ed esegue dati non eseguibili, sfruttando l\u2019hardware (bit NX) e marcando anche regioni di memoria come <strong>non accessibili<\/strong> quando opportuno (es. mappe null pointer per catturare dereferenziazioni errate). Da un punto di vista offensivo, molti malware tentano di aggirare queste protezioni, ad esempio tramite <em>Return-Oriented Programming<\/em> (ROP) per eseguire codice malizioso pur in assenza di pagine eseguibili in user-space: analizzare un attacco del genere richiede padronanza di come il SO organizza la memoria di un processo.<\/li>\n\n\n\n<li><strong>File system e gestione delle risorse persistenti<\/strong>: un altro compito cardine del sistema operativo \u00e8 la gestione dei <strong>file system<\/strong>, ovvero l\u2019organizzazione dei dati su memoria di massa (dischi, SSD) in file e directory, con meccanismi di autorizzazione (permessi di lettura\/scrittura\/esecuzione per utenti e gruppi) e di protezione. Per esempio, sistemi POSIX (Linux, UNIX) adottano permessi <strong>rwx<\/strong> e propriet\u00e0 utente\/gruppo, oltre a meccanismi pi\u00f9 avanzati come <strong>ACL<\/strong> (Access Control List) o <em>selinux context<\/em> per definire in modo granulare chi pu\u00f2 accedere a cosa. Un responsabile della sicurezza deve assicurarsi che le politiche di permesso siano configurate secondo il principio del privilegio minimo (ad esempio, file di configurazione critici accessibili solo all\u2019utente di sistema appropriato, directory con dati sensibili non eseguibili, ecc.). Inoltre, il file system registra metadati come timestamp (utili nelle analisi forensi per capire la timeline di un incidente) e, in alcuni sistemi, supporta cifratura trasparente (es. BitLocker su NTFS, LUKS su ext4) per proteggere i dati a riposo. Il sistema operativo \u00e8 anche responsabile della <strong>gestione delle periferiche<\/strong> tramite <strong>driver<\/strong> \u2013 piccoli moduli software che fungono da traduttori tra il kernel e l\u2019hardware. Driver vulnerabili possono introdurre gravi falle di sicurezza (poich\u00e9 eseguono in kernel mode), quindi l\u2019OS e i suoi aggiornamenti vanno monitorati per patch critiche relative ai driver (come ad esempio <em>stuxnet<\/em>, che sfrutt\u00f2 un driver malevolo con firma digitale rubata). Il sistema operativo implementa anche politiche di <strong>controllo degli accessi<\/strong> non solo a file ma a tutte le risorse (dispositivi, porte di rete, chiamate di sistema sensibili). Ad esempio, su sistemi UNIX esiste la distinzione tra utente normale e <strong>superutente (root)<\/strong>: solo quest\u2019ultimo pu\u00f2 eseguire certe operazioni (binding di socket su porte &lt;1024, caricamento di moduli kernel, modifiche alle tabelle di routing, ecc.). Meccanismi di <em>sudo<\/em> o <em>capabilities<\/em> permettono di limitare o delegare privilegi in modo controllato. La corretta configurazione di questi meccanismi \u00e8 spesso l\u2019ultima linea di difesa per prevenire che un attacco su un servizio in esecuzione con utente limitato comprometta tutto il sistema.<\/li>\n\n\n\n<li><strong>Interfaccia utente e modalit\u00e0 utente\/kernel<\/strong>: il sistema operativo fornisce infine all\u2019utente (e alle applicazioni) un\u2019interfaccia per utilizzare il computer. Questa pu\u00f2 essere una <strong>GUI<\/strong> (interfaccia grafica) con desktop, finestre e pulsanti, o una <strong>shell a riga di comando<\/strong> per lanciare comandi testuali. Indipendentemente dall\u2019interfaccia, quando un\u2019applicazione necessita di compiere operazioni privilegiate (es. accedere al disco, aprire una connessione di rete, allocare memoria), deve effettuare una <strong>chiamata di sistema (system call)<\/strong> al kernel. Le system call rappresentano il <strong>punto di controllo<\/strong> tra la modalit\u00e0 utente e la modalit\u00e0 kernel: l\u2019OS espone una serie di servizi di sistema (come \u201copen file\u201d, \u201csend packet\u201d, \u201ccreate process\u201d) e gli unici modi per un programma di utente di ottenere questi servizi \u00e8 invocare le relative chiamate, che comportano un trap in modalit\u00e0 privilegiata. Il sistema operativo verifica i parametri e i permessi ad ogni system call, garantendo che l\u2019operazione sia lecita. Ad esempio, se un processo chiede di aprire un file, il kernel controlla che quel processo (identificato dal suo UID\/GID di appartenenza) abbia i diritti necessari sul file. Questo meccanismo \u00e8 fondamentale per la sicurezza: previene che un processo malevolo possa arbitrariamente manipolare risorse senza passare per controlli. D\u2019altra parte, se esistono vulnerabilit\u00e0 nelle implementazioni delle system call (bug nel kernel), un attaccante potrebbe ottenere privilegi elevati \u2013 questi sono i famosi exploit <em>local root<\/em> che sfruttano race condition, buffer overflow o errori logici nel kernel. Un buon responsabile della sicurezza deve tenere i sistemi operativi aggiornati (<em>patch management<\/em>) proprio per correggere tali vulnerabilit\u00e0 non appena note.<\/li>\n<\/ul>\n\n\n\n<p>In conclusione, il sistema operativo \u00e8 il componente software pi\u00f9 critico da un punto di vista di sicurezza, perch\u00e9 <strong>orchestra l\u2019uso di tutte le risorse e applica le politiche di isolamento e controllo<\/strong>.<br>Le best practice come la separazione dei privilegi (account utente vs amministratore), la riduzione della <em>superficie d\u2019attacco<\/em> (disabilitare servizi di sistema non necessari, rimuovere driver inutilizzati), l\u2019uso di meccanismi di <em>logging<\/em> e monitoraggio (Syslog, Event Viewer) e l\u2019applicazione tempestiva di aggiornamenti di sicurezza, sono tutti ambiti afferenti al sistema operativo. Inoltre, standard e linee guida come quelle di <strong>CIS (Center for Internet Security)<\/strong> forniscono benchmark di hardening specifici per i vari sistemi operativi (ad esempio, <em>CIS Controls<\/em> e <em>CIS Benchmarks<\/em> per Windows Server, Red Hat, etc.), che il responsabile dovrebbe adottare per assicurare una configurazione robusta delle macchine. Un sistema operativo correttamente configurato e mantenuto \u00e8 in grado di prevenire la maggior parte degli incidenti informatici comuni (attacchi malware, escalation di privilegi, esfiltrazione di dati), o quantomeno di registrare eventi utili a rilevare tempestivamente attivit\u00e0 anomale.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-279a2f357c07e4aa4b132e939ba66854\"><strong>Basi di dati relazionali e NoSQL<\/strong><\/p>\n\n\n\n<p>Le <strong>basi di dati (database)<\/strong> sono infrastrutture fondamentali per archiviare, organizzare e recuperare grandi quantit\u00e0 di informazioni in modo efficiente. Esistono vari modelli di database; i pi\u00f9 diffusi si dividono in <strong>database relazionali (SQL)<\/strong> e <strong>database NoSQL (non relazionali)<\/strong>. In questa sezione esamineremo entrambi, delineando caratteristiche, differenze e rilevanza per la sicurezza.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Database relazionali (modello SQL)<\/strong><\/p>\n\n\n\n<p>Un <strong>database relazionale<\/strong> organizza i dati in tabelle composte da righe e colonne, secondo il modello introdotto da Edgar F. Codd negli anni \u201870. Ogni tabella rappresenta un\u2019entit\u00e0, ogni riga (o <em>record<\/em>) rappresenta un\u2019istanza dell\u2019entit\u00e0 e ogni colonna rappresenta un attributo (campo) del record. Ad esempio, potremmo avere una tabella <em>Utenti<\/em> con colonne <em>ID, Nome, Email, Ruolo<\/em> dove ciascuna riga \u00e8 un utente specifico con i suoi dati e una tabella <em>Accessi<\/em> con colonne <em>UtenteID, DataOra, Esito<\/em> per tracciare i login: le due tabelle sarebbero collegate attraverso il campo <em>UtenteID<\/em> (chiave esterna nella tabella Accessi che rimanda alla chiave primaria ID nella tabella Utenti). <strong>Le relazioni<\/strong> tra tabelle (one-to-one, one-to-many, many-to-many) vengono realizzate tramite queste chiavi: chiave primaria (un identificatore unico per ogni riga di una tabella) e chiavi esterne (valori che collegano una riga a una riga in un\u2019altra tabella). Il modello relazionale \u00e8 accompagnato da un linguaggio standard di interrogazione e manipolazione dei dati: <strong>SQL (Structured Query Language)<\/strong>, che permette di definire lo schema (DDL \u2013 Data Definition Language), inserire\/modificare\/cancellare dati (DML \u2013 Data Manipulation Language) e effettuare query di ricerca e aggregazione (con SELECT, JOIN tra tabelle, ecc.).<\/p>\n\n\n\n<p>Caratteristiche chiave dei database relazionali sono le cosiddette propriet\u00e0 <strong>ACID <\/strong>delle transazioni, fondamentali in ambiti critici (bancari, gestionali, etc.): <strong>Atomicit\u00e0 <\/strong>(ogni transazione \u00e8 un\u2019unit\u00e0 indivisibile, o tutti gli step vengono applicati o nessuno), <strong>Coerenza <\/strong>(la transazione porta il database da uno stato consistente a un altro, non viola vincoli di integrit\u00e0 ), <strong>Isolamento <\/strong>(transazioni concorrenti non interferiscono tra loro, i risultati sono come se fossero state eseguite in sequenza) e <strong>Durabilit\u00e0 <\/strong>(una volta completata con successo, un\u2019operazione diventa persistente anche in caso di guasti successivi). I DB relazionali sono tipicamente gestiti da un <strong>RDBMS <\/strong>(Relational Database Management System) \u2013 ad esempio Oracle, Microsoft SQL Server, MySQL\/MariaDB, PostgreSQL \u2013 che si occupa di implementare queste garanzie e ottimizzare l\u2019accesso ai dati (attraverso indici, piani di esecuzione delle query, caching, etc.).<\/p>\n\n\n\n<p><strong>Rilevanza per la sicurezza:<\/strong> i database relazionali spesso custodiscono informazioni sensibili (dati personali, credenziali, registri di attivit\u00e0) e sono bersagli appetibili per gli attaccanti. Due aspetti fondamentali vanno considerati: la <strong>sicurezza interna del DB<\/strong> e le <strong>vulnerabilit\u00e0 delle applicazioni<\/strong> che lo utilizzano. Sul primo fronte, un RDBMS deve essere configurato con opportune misure di sicurezza: controlli di accesso robusti (account separati con privilegi minimi per le applicazioni, ruoli e privilegi SQL assegnati con granularit\u00e0), cifratura dei dati a riposo (molti DB supportano tablespace criptati o cifratura trasparente delle colonne), audit e logging delle operazioni (tracciare chi ha eseguito cosa e quando, per individuare accessi sospetti) e hardening generale (disabilitare funzionalit\u00e0 non utilizzate, applicare patch di sicurezza del motore DB). Ad esempio, esistono standard come lo <strong>SQL Server Security Guide<\/strong> o linee guida CIS Benchmarks per MySQL\/PostgreSQL che elencano best practice: dal forzare l\u2019autenticazione con password complesse, all\u2019abilitare la cifratura TLS nelle connessioni client-DB, fino a restringere l\u2019uso di stored procedure o comandi pericolosi solo ad account fidati.<\/p>\n\n\n\n<p>Sul secondo fronte, il rischio pi\u00f9 noto \u00e8 la <strong>SQL Injection<\/strong>, una tecnica d\u2019attacco applicativa in cui input malevoli forniti a un\u2019applicazione web (o altro software) finiscono per alterare l\u2019istruzione SQL eseguita sul database. Se l\u2019applicazione non \u201csanitizza\u201d correttamente gli input (ad esempio non usando query parametrizzate\/preparate), un attaccante pu\u00f2 inserire frammenti di SQL arbitrario nelle query, ottenendo potenzialmente accesso o manipolazione non autorizzata dei dati. Un classico incidente \u00e8 quando un campo di login viene usato direttamente in una query tipo <code>SELECT * FROM utenti WHERE user='${utente}' AND pass='${password}'<\/code> : fornendo come utente qualcosa come <code>' OR '1'='1' <\/code>, la query diventa sempre vera permettendo bypass di autenticazione. Dal punto di vista di un responsabile alla sicurezza, mitigare le SQL injection \u00e8 prioritario: significa formare gli sviluppatori all\u2019uso di parametri bindati, ORMs, stored procedure sicure e al filtraggio\/escape degli input in ultima istanza. In aggiunta, predisporre <strong>Web Application Firewall (WAF)<\/strong> con regole per intercettare pattern di SQL injection pu\u00f2 aggiungere un livello di difesa. Un altro esempio di attacco \u00e8 il <strong>privilege escalation interno al DB<\/strong>: se un account di applicazione con pochi privilegi riesce a eseguire un comando di sistema attraverso una funzionalit\u00e0 di SQL estesa (ad esempio le <em>xp_cmdshell<\/em> di SQL Server, se abilitate impropriamente, consentono di eseguire comandi sul sistema operativo), l\u2019attaccante potrebbe passare dal database al pieno controllo del server. Ci\u00f2 evidenzia l\u2019importanza di limitare al minimo i privilegi degli account DB usati dalle applicazioni e di disabilitare funzionalit\u00e0 di estensione (come esecuzione di codice esterno) se non necessarie.<\/p>\n\n\n\n<p>In termini di standard, normative come il <strong>GDPR<\/strong> richiedono protezione rigorosa dei dati personali spesso contenuti nei database, includendo principi di <em>data protection by design<\/em> (ad esempio minimizzazione dei dati raccolti, pseudonimizzazione). Standard industriali come il <strong>PCI-DSS<\/strong> per i dati di carte di credito impongono cifratura degli storage e segmentazione di rete per i sistemi di database, oltre a monitoraggio continuo degli accessi.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Database NoSQL (non relazionali)<\/strong><\/p>\n\n\n\n<p>Negli ultimi anni, accanto ai sistemi relazionali tradizionali, si sono diffusi i <strong>database NoSQL<\/strong>, termine che sta per \u201cNot Only SQL\u201d ad indicare database non basati sul modello relazionale e spesso privi di schema fisso. I database NoSQL abbracciano diverse categorie: database <em>documentali <\/em>(che memorizzano dati in documenti strutturati tipicamente in formato JSON\/BSON, es. MongoDB, CouchDB), database a <em>colonne distribuite<\/em> (simili a tabelle sparse con colonne flessibili, es. Cassandra, HBase), database a <em>chiave-valore<\/em> (memorizzano coppie key-value senza struttura interna, es. Redis, Riak) e database a <em>grafo<\/em> (ottimizzati per rappresentare entit\u00e0 e relazioni complesse come nodi e archi, es. Neo4j). Questi sistemi rinunciano alle rigide tabelle relazionali in favore di una struttura dati pi\u00f9 flessibile e spesso distribuita su cluster di macchine.<\/p>\n\n\n\n<p>Nei database NoSQL, i dati vengono spesso memorizzati nel loro <strong>formato nativo<\/strong> o \u201cdenormalizzato\u201d. Ad esempio, un documento JSON pu\u00f2 contenere in un unico record tutte le informazioni di un utente, compresa una lista dei suoi ordini, evitando di fare JOIN tra tabelle separate come accadrebbe in un<br>modello relazionale. Questo porta vantaggi in termini di prestazioni e scalabilit\u00e0 su grandi volumi di dati o dati eterogenei: il sistema <strong>scala orizzontalmente<\/strong>, replicando e partizionando i dati su pi\u00f9 nodi (sharding), ed \u00e8 in grado di gestire variazioni di struttura tra diversi record (schema flessibile).<\/p>\n\n\n\n<p>Tuttavia, spesso i database NoSQL <strong>sacrificano la coerenza immediata<\/strong> delle transazioni in favore della disponibilit\u00e0 e della partition tolerance, secondo i principi del teorema <strong>CAP<\/strong>. In ambienti distribuiti, garantire simultaneamente Coerenza, Disponibilit\u00e0 e Tolleranza alle partizioni \u00e8 impossibile; molti database NoSQL scelgono di essere AP (available, partition-tolerant) sacrificando la consistenza forte: i dati possono essere <em>eventualmente consistenti<\/em>, ovvero gli aggiornamenti si propagano con tempo breve ma non istantaneo su tutte le repliche. In termini pratici, ci\u00f2 significa che una lettura potrebbe restituire un dato lievemente obsoleto se appena modificato altrove, privilegiando per\u00f2 la reattivit\u00e0 del sistema anche in caso di rete con latenze. Questo \u00e8 spesso accettabile per scenari come social network (ad esempio, vedere per qualche secondo la vecchia foto profilo di un utente prima che arrivi la nuova non \u00e8 critico), ma sarebbe inaccettabile in un\u2019applicazione bancaria (dove i conti correnti richiedono consistenza forte). In compenso, le architetture NoSQL sono progettate per <strong>alta disponibilit\u00e0 e scalabilit\u00e0<\/strong>: aggiungendo nodi al cluster, le performance di throughput aumentano linearmente in molti casi e la ridondanza dei dati su nodi multipli evita singoli punti di guasto.<\/p>\n\n\n\n<p><strong>Rilevanza per la sicurezza<\/strong>: i database NoSQL presentano sfide di sicurezza in parte analoghe a quelle dei relazionali, ma con alcune peculiarit\u00e0. Innanzitutto, l\u2019<strong>assenza di schema fisso<\/strong> significa che non ci sono vincoli intrinseci di tipo\/forma dei dati: ci\u00f2 pu\u00f2 rendere pi\u00f9 difficile validare l\u2019input e pi\u00f9 facile commettere errori logici (ad esempio, se un campo previsto come numero intero viene memorizzato come stringa in alcuni documenti, il comportamento dell\u2019applicazione potrebbe essere imprevedibile).<br>Dal punto di vista degli attacchi, esistono varianti di injection anche per NoSQL \u2013 le cosiddette <strong>NoSQL Injection<\/strong> \u2013 dove input malevoli manipolano le query di ricerca su database non relazionali. Ad esempio, in MongoDB una query \u00e8 spesso costruita passando un JSON di filtro: se un\u2019applicazione web inserisce direttamente parametri utente in questo JSON senza controlli, un attaccante potrebbe aggiungere operatori come <code>$gt<\/code> (greater than) o <code>$ne<\/code> (not equal) per alterare la logica della query. Pur meno note delle SQL injection, vulnerabilit\u00e0 analoghe sono state riscontrate (ad es. su applicazioni con backend MongoDB, Redis injection sfruttando comandi craftati, ecc.).<\/p>\n\n\n\n<p>In termini di <strong>controlli di accesso<\/strong>, alcuni database NoSQL nelle prime versioni erano pensati per funzionare in ambienti fidati e mancavano di robusti sistemi di autenticazione\/autorizzazione. Ci sono stati casi clamorosi di database NoSQL esposti online senza password (es. istanze di MongoDB o Elasticsearch lasciate aperte) che hanno portato a massivi furti di dati o attacchi ransomware (dove gli attaccanti esfiltravano e cancellavano i dati chiedendo un riscatto). Dunque, una prima regola di sicurezza \u00e8 assicurarsi che l\u2019<strong>accesso di rete ai database<\/strong> sia segregato (solo dagli application server, non dal pubblico internet) e che i meccanismi di autenticazione siano attivi e con credenziali robuste.<br>Oggi i principali prodotti NoSQL (MongoDB, Cassandra, etc.) offrono meccanismi di autenticazione, cifratura in transito (SSL\/TLS) e a riposo, controlli di autorizzazione basati su ruoli \u2013 ma sta ai configuratori abilitarli. In un contesto di sicurezza nazionale, dove si trattano dati sensibili, \u00e8 imperativo che anche i database NoSQL rispettino standard di hardening: ad esempio, <strong>MongoDB Security Checklist<\/strong> suggerisce di abilitare l\u2019autenticazione SCRAM-SHA, definire ruoli con minimo privilegio (lettura\/scrittura su specifici database), usare IP binding solo su interfacce interne, abilitare auditing, ecc.<\/p>\n\n\n\n<p>Dal punto di vista della <strong>consistenza dei dati<\/strong>, bisogna inoltre considerare la resilienza: in caso di incidenti (es. guasto di nodi, partizioni di rete), i database NoSQL possono entrare in stati degradati (consistenza ridotta) che, se non gestiti, potrebbero causare perdite o duplicazioni di dati. Un piano di sicurezza deve includere backup regolari anche per database NoSQL e test di ripristino, dato che la natura distribuita a volte complica le procedure di recovery (bisogna tenere conto di <em>replica set<\/em>, <em>quorum<\/em> di consenso per riottenere un primario in sistemi tipo MongoDB, etc.). Inoltre, la <em>eventuale consistenza<\/em> implica che nel monitoraggio degli incidenti bisogna tener conto di possibili discrepanze temporanee: ad esempio, analizzando i log di un sistema distribuito, un responsabile alla sicurezza deve sapere che l\u2019ordine esatto delle operazioni potrebbe differire leggermente tra nodi \u2013 il che pu\u00f2 complicare l\u2019analisi forense e la ricostruzione esatta degli eventi. Strumenti specializzati per logging centralizzato (spesso basati essi stessi su stack NoSQL, come ELK \u2013 Elasticsearch, Logstash, Kibana) vanno configurati per correlare correttamente eventi multi-nodo.<\/p>\n\n\n\n<p><strong>Integrazione SQL\/NoSQL e best practice<\/strong>: molte organizzazioni adottano architetture ibride dove convivono database relazionali per dati transazionali e database NoSQL per big data, analytics in tempo reale, cache in-memory, etc. Un coordinatore di sicurezza deve avere familiarit\u00e0 con entrambi e con le tecniche per proteggerli. Ad esempio, assicurarsi che i dati sensibili presenti in un cluster Hadoop\/NoSQL siano cifrati (usando magari librerie come Google Tink o servizi KMS per gestire le chiavi) e segregati con <em>tokenization<\/em> o <em>pseudonymization<\/em> per minimizzare l\u2019impatto di un breach. Allo stesso tempo, mantenere aggiornati i sistemi (le piattaforme NoSQL sono in continuo sviluppo, patch di sicurezza escono di frequente) e utilizzare strumenti di monitoraggio delle anomalie sulle query (Database Activity Monitoring) anche su NoSQL, dove possibile, per rilevare pattern inconsueti (es. un\u2019esplosione di letture anomale alle 3 di notte da un certo IP potrebbe indicare un exfiltration in corso).<\/p>\n\n\n\n<p>Riassumendo, la scelta tra database relazionali e NoSQL dipende dai requisiti di consistenza, scalabilit\u00e0 e struttura dei dati. Dal punto di vista della sicurezza, <em>entrambi<\/em> richiedono robuste misure di protezione, consapevoli delle rispettive architetture. I database relazionali brillano per maturit\u00e0 di strumenti di sicurezza integrati e transazioni ACID, mentre i NoSQL offrono flessibilit\u00e0 e prestazioni su scala, ma il professionista deve compensare eventuali mancanze (es. consistenza) a livello applicativo e prestare attenzione a configurazioni sicure che <em>non sono sempre default<\/em>. Conoscere standard come <strong>OWASP Top 10 (A03:2021 \u2013 Injection)<\/strong> per le injection o il <strong>NIST SP 800-123<\/strong> (guide to general server security, applicabile anche ai server DB) aiuta a costruire un ambiente database \u2013 relazionale o no \u2013 robusto contro incidenti informatici.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-6e918cbb8aa45f6d9e8620bd5fc58455\"><strong>Networking e principali protocolli di rete (TCP\/IP, DNS, BGP)<\/strong><\/p>\n\n\n\n<p>Le <strong>reti di calcolatori<\/strong> permettono a sistemi differenti di comunicare e scambiarsi informazioni. La sicurezza informatica moderna \u00e8 strettamente legata alle reti, poich\u00e9 gran parte degli incidenti avviene attraverso connessioni di rete (attacchi remoti, malware che si propagano, esfiltrazioni di dati). In questa sezione esaminiamo i fondamenti del networking e tre protocolli chiave: la suite <strong>TCP\/IP<\/strong> (base di Internet), il sistema dei nomi a dominio <strong>DNS<\/strong> e il protocollo di routing <strong>BGP. <\/strong>Comprendere questi protocolli \u00e8 essenziale per prevenire e gestire incidenti che vanno dagli attacchi DDoS alla manipolazione del traffico internet.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Suite TCP\/IP (Livelli di trasporto e rete)<\/strong><\/p>\n\n\n\n<p><strong>TCP\/IP<\/strong> non \u00e8 un singolo protocollo ma una famiglia di protocolli organizzati in un modello di rete pratico (spesso semplificato in 4 livelli: Link, Internet, Trasporto, Applicazione) che corrisponde in parte al modello OSI (vedi sezione successiva). I due pilastri di questa suite sono il <strong>Protocollo IP<\/strong> (Internet Protocol) e il <strong>Protocollo TCP<\/strong> (Transmission Control Protocol), da cui prende nome.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IP (Internet Protocol)<\/strong>: IP opera al livello di <strong>rete<\/strong> ed \u00e8 il protocollo fondamentale che si occupa di indirizzamento e instradamento dei pacchetti attraverso reti differenti. IP fornisce un servizio di consegna di pacchetti <em>non affidabile e senza connessione<\/em>: ci\u00f2 significa che invia i pacchetti dal mittente al destinatario secondo le informazioni di routing, ma non garantisce n\u00e9 che arrivino (possono perdersi) n\u00e9 che arrivino in ordine. Ogni dispositivo collegato in rete ha almeno un <strong>indirizzo IP<\/strong> univoco (32 bit per IPv4, rappresentati come quattro numeri es. 192.168.10.5, oppure 128 bit per IPv6, rappresentati in esadecimale). IP provvede a incapsulare i dati in un <strong>pacchetto IP<\/strong> contenente header (con mittente, destinatario, TTL, ecc.) e payload (i dati da trasportare, ad esempio un segmento TCP). Il protocollo IP \u00e8 progettato per collegare reti eterogenee: \u00e8 un protocollo di interconnessione di reti (<em>internetworking<\/em>) di livello 3 OSI, nato per far comunicare sottoreti differenti unificandole in un\u2019unica rete logica (da cui \u201cInternet\u201d). IP compie l\u2019instradamento: i router analizzano l\u2019indirizzo di destinazione IP di ciascun pacchetto e lo inoltrano verso il router successivo pi\u00f9 vicino alla destinazione, sulla base di tabelle di routing. Gli algoritmi di routing (OSPF, BGP, ecc. visti pi\u00f9 avanti per BGP) costruiscono queste tabelle. Sul piano sicurezza, IP di per s\u00e9 non prevede autenticazione n\u00e9 confidenzialit\u00e0: i pacchetti possono essere falsificati (IP spoofing) e letti da intermediari. Per ovviare a ci\u00f2 esistono estensioni come <strong>IPsec<\/strong> (una suite per la cifratura e autenticazione a livello IP) usata in VPN sicure. Inoltre, la natura non affidabile di IP significa che spetta ai livelli superiori occuparsi di ritrasmissioni e controllo di flusso (\u00e8 qui che interviene TCP). Va citato che IPv4 soffre di spazio di indirizzi limitato e problemi di sicurezza (frammentazione IP usata in certi attacchi DoS, ad esempio <em>Teardrop attack<\/em>), mentre <strong>IPv6<\/strong> migliora alcuni aspetti (spazio vastissimo, meccanismi di autoconfigurazione) ma porta nuove considerazioni di sicurezza (ad esempio, la presenza obbligatoria di ICMPv6 e multicast di rete locale richiede filtri specifici per evitare scansioni e  attacchi di discovery non autorizzati).<\/li>\n\n\n\n<li><strong>TCP (Transmission Control Protocol)<\/strong>: TCP opera a <strong>livello di trasporto<\/strong> e fornisce un canale di comunicazione affidabile e orientato alla connessione tra due host. In termini pratici, TCP si occupa di instaurare una connessione virtuale tra client e server (tramite la celebre stretta di mano <strong>3-way handshake<\/strong>: SYN, SYN-ACK, ACK), di suddividere i dati da inviare in segmenti adeguati, di numerare i segmenti e ritrasmettere quelli non riconosciuti e di riordinare i segmenti al ricevente per presentare un flusso di byte continuo all\u2019applicazione. Grazie a TCP, le applicazioni non devono preoccuparsi di perdita o disordine di pacchetti: TCP garantisce che i dati arrivino integri e nell\u2019ordine corretto, o notifica un errore se la connessione si interrompe. Questo \u00e8 essenziale per protocolli applicativi come HTTP, SMTP, FTP, in cui ricevere dati incompleti o scombinati equivarrebbe a corruzione dell\u2019informazione. Tecnicamente, TCP identifica le connessioni tramite le <strong>porte<\/strong>: ogni segmento TCP ha una porta sorgente e una destinazione, permettendo a un singolo host di gestire pi\u00f9 connessioni simultanee su porte diverse (es. 80 per HTTP, 443 per HTTPS, 25 per SMTP, ecc.). Dal punto di vista della sicurezza, il protocollo TCP \u00e8 stato bersaglio di attacchi sin dai primordi di Internet. Un esempio classico \u00e8 il <strong>TCP SYN flood<\/strong>: attaccando l\u2019handshake di TCP, un aggressore invia una valanga di pacchetti SYN senza completare mai il 3\u00b0 passo, lasciando il server con molte connessioni \u201cmezze aperte\u201d (in stato SYN_RECV) e esaurendo le risorse dedicate (la <em>backlog queue<\/em>). Ci\u00f2 provoca un Denial of Service. Contromisure come <strong>SYN cookies<\/strong> o limiti sulla half-open queue aiutano a mitigare. Un altro attacco \u00e8 il <strong>TCP reset (RST)<\/strong>: inviando un pacchetto falsificato con bit RST si pu\u00f2 forzare la chiusura di una connessione TCP esistente; se l\u2019attaccante riesce a indovinare gli identificatori corretti (IP\/porta e numero di sequenza), pu\u00f2 interrompere comunicazioni di altri. Questo fu sfruttato in passato per bloccare traffico BGP (il cui trasporto \u00e8 su TCP, vedi dopo) o per censura (come RST injection nel grande firewall cinese). Per integrit\u00e0 e confidenzialit\u00e0, TCP da solo non offre nulla: la protezione dei dati deve avvenire a livello applicativo (ad es. TLS sopra TCP per cifrare la sessione). Tuttavia, <em>dentro<\/em> la suite TCP\/IP esistono protocolli complementari come UDP (User Datagram Protocol, non affidabile e senza connessione, usato per streaming, DNS, etc.) che il responsabile sicurezza deve ugualmente conoscere: ad esempio, <strong>UDP<\/strong> \u00e8 pi\u00f9 soggetto a spoofing (essendo connectionless) e viene sfruttato in attacchi DDoS di riflessione\/amplificazione (come DNS amplification, SSDP amplification), dunque vanno predisposti filtri (e.g. anti-spoofing con <em>BCP 38<\/em>, rate limiting su servizi UDP pubblici). In generale, la comprensione profonda di TCP\/IP consente di analizzare i <strong>log di rete<\/strong> e i <strong>dump di pacchetto<\/strong> (es. con Wireshark) per rilevare attivit\u00e0 sospette: sequenze anomale di flag TCP, tentativi su port scanning (che si evidenziano come connessioni SYN brevissime su molte porte), pacchetti malformati, etc. Standard come gli <strong>RFC<\/strong> (es. RFC 793 per TCP, RFC 791 per IP) definiscono il funzionamento lecito: molti attacchi inviano traffico che devia dallo standard (es. pacchetti con flag inconsuete come Xmas scan con FIN-PSH-URG) e sistemi IDS\/IPS (Snort, Suricata, Zeek) sono in grado di rilevarlo se ben configurati.<\/li>\n<\/ul>\n\n\n\n<p>In sintesi, <strong>TCP\/IP \u00e8 la colonna portante delle comunicazioni di rete<\/strong>. Un coordinatore di prevenzione incidenti deve: assicurare che le configurazioni di rete seguano le best practice (filtri su pacchetti ingressi\/uscita, disabilitare protocolli legacy insicuri \u2013 es. Telnet, FTP \u2013 a favore di versioni cifrate \u2013 SSH, FTPS\/SFTP), conoscere gli attacchi di rete comuni e le contromisure (firewall stateful per gestire SYN flood, IDS per rilevare scansioni e anomalie TCP\/IP, IPsec per proteggere canali critici) e in caso di incidente saper leggere il traffico (analisi PCAP) per capire cosa \u00e8 successo. Ad esempio, in un sospetto data breach, potrebbe trovarsi traffico TCP sulla porta 443 di volume insolitamente alto verso un IP esterno non riconosciuto: sapere che 443 \u00e8 solitamente HTTPS e che l\u2019esfiltrazione potrebbe avvenire cifrata fa s\u00ec che si debba guardare a meta-dati (SNI, quantit\u00e0, pattern) e non al contenuto impossibile da decifrare senza la chiave. Allo stesso modo, la padronanza di TCP\/IP \u00e8 fondamentale per gestire incidenti come <strong>DDoS<\/strong>: riconoscere un flood TCP SYN o UDP, distinguere un traffico legittimo da uno malevolo in base a parametri di basso livello e interfacciarsi con ISP\/CDN per attivare filtri o scrubbing.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>DNS (Domain Name System)<\/strong><\/p>\n\n\n\n<p><strong>DNS<\/strong> \u00e8 il \u201cservizio di nomi\u201d di Internet, spesso paragonato a un \u201celenco telefonico\u201d o a un servizio di rubrica per la rete globale. Il suo scopo principale \u00e8 tradurre i nomi di dominio leggibili dagli umani (ad es. <code>www.esempio.gov<\/code>) nei corrispondenti indirizzi IP numerici che le macchine utilizzano per instradare il traffico. Senza DNS, dovremmo ricordare e digitare indirizzi come <code>93.184.216.34<\/code> per visitare un sito, cosa impraticabile su larga scala. Il DNS \u00e8 dunque fondamentale per l\u2019usabilit\u00e0 di Internet.<\/p>\n\n\n\n<p>Il sistema DNS \u00e8 <strong>gerarchico e distribuito<\/strong>. I nomi di dominio sono organizzati in una struttura ad albero rovesciato: al vertice ci sono i <strong>root server<\/strong> (indicati da un dominio radice vuoto, spesso rappresentato da un punto<code> . <\/code>), subito sotto ci sono i domini di primo livello (TLD) come <code>.com <\/code>,<code> .org <\/code>,<code> .it <\/code>,<code> .gov<\/code>, ecc., poi i secondi livelli (es. <code>esempio<\/code> in <code>esempio.gov <\/code>) e cos\u00ec via con possibili sottodomini aggiuntivi. L\u2019operazione di <strong>risoluzione DNS<\/strong> consiste nel trovare l\u2019indirizzo IP associato a un nome (risoluzione diretta) o viceversa trovare il nome dato un IP (risoluzione inversa). Quando un client (tipicamente tramite un resolver stub integrato nel sistema operativo) deve risolvere un nome, contatta un <strong>DNS resolver ricorsivo<\/strong> (spesso fornito dall\u2019ISP o configurato manualmente come 8.8.8.8 di Google) il quale interroga a sua volta la gerarchia: parte dai root server (ce ne sono 13 indirizzi logici root disseminati globalmente) per sapere chi \u00e8 autoritativo per il TLD richiesto, poi contatta il server autoritativo di quel TLD per sapere chi gestisce il dominio di secondo livello e cos\u00ec via fino ad ottenere dal server DNS autoritativo finale (gestito dal proprietario del dominio o dal suo provider) il record richiesto. Il DNS memorizza le risposte in <strong>cache<\/strong> per un certo periodo (TTL) per accelerare richieste future.<\/p>\n\n\n\n<p>I <strong>record DNS<\/strong> pi\u00f9 comuni includono: <strong>A\/AAAA<\/strong> (indirizzo IPv4 o IPv6 associato a un nome), <strong>CNAME<\/strong> (nome canonico, alias verso un altro nome), <strong>MX<\/strong> (mail exchanger, indirizzo dei server di posta per il dominio), <strong>TXT<\/strong> (testo libero, usato anche per record SPF\/DKIM nei contesti mail), <strong>SRV<\/strong> (service locator, utilizzato da alcuni protocolli), <strong>PTR<\/strong> (pointer per risoluzione inversa da IP a nome).<\/p>\n\n\n\n<p><strong>Minacce e sicurezza DNS<\/strong>: il DNS in origine \u00e8 stato progettato senza meccanismi di autenticazione, il che l\u2019ha reso vulnerabile a vari attacchi. Il pi\u00f9 classico \u00e8 il <strong>DNS cache poisoning<\/strong>: un attaccante induce un resolver a memorizzare una risposta falsa, cosicch\u00e9 gli utenti successivi vengano indirizzati all\u2019IP sbagliato (ad esempio, credono di visitare <code>bancopopolare.it<\/code> ma in realt\u00e0 il DNS avvelenato gli d\u00e0 l\u2019IP di un server dell\u2019attaccante). Prima di correttivi, era possibile inviare risposte DNS fasulle con una certa facilit\u00e0, approfittando del fatto che la porta UDP 53 e l\u2019ID di transazione DNS erano prevedibili e non c\u2019era verifica di origine. Ora i resolver usano porte effimere random e ID random a 16 bit, riducendo la fattibilit\u00e0 del poisoning, ma il rischio resta se l\u2019attaccante pu\u00f2 intralciare la comunicazione col vero server (ad es. tramite un man-in-the-middle). La risposta dell\u2019industria \u00e8 <strong>DNSSEC<\/strong>, un\u2019estensione di sicurezza che aggiunge firme digitali alle risposte DNS: i domini firmati DNSSEC pubblicano chiavi pubbliche nei record <strong>DNSKEY<\/strong> e usano record <strong>RRSIG<\/strong> per firmare le mapping nome-&gt;IP. Un resolver con DNSSEC abilitato verifica che la firma sia valida e ancorata a una catena di fiducia (dal root in gi\u00f9) evitando di accettare dati manomessi. DNSSEC, per\u00f2, non \u00e8 ancora ovunque adottato e introduce la<br>complessit\u00e0 della gestione chiavi\/rollover.<\/p>\n\n\n\n<p>Un altro problema di sicurezza DNS \u00e8 il <strong>DNS tunneling<\/strong>: usando richieste DNS (che spesso sono permesse anche quando altro traffico \u00e8 bloccato) per incapsulare dati arbitrari, degli attaccanti possono esfiltrare informazioni o comandare malware (comandi e controllo) attraverso query DNS apparentemente legittime. Ad esempio, un malware potrebbe fare query a sottodomini come <code>&lt;data&gt;.esempio-attaccante.com<\/code>, dove <code>&lt;data&gt;<\/code> \u00e8 un blocco di dati rubati codificato in base32; il server DNS sotto il controllo dell\u2019attaccante riceve queste query e decodifica i dati dal nome richiesto.<br>Dal punto di vista di un analista, \u00e8 importante monitorare il traffico DNS verso domini insoliti o con nomi molto lunghi\/strani, segnale tipico di tunneling o <em>data exfiltration<\/em>. Strumenti di sicurezza avanzata (DNS firewall, soluzioni di <em>exfiltration detection<\/em>) possono rilevare e bloccare questi abusi.<\/p>\n\n\n\n<p>C\u2019\u00e8 poi il <strong>DNS hijacking<\/strong> o <em>DNS spoofing<\/em>: se un attaccante compromette un server DNS autoritativo o modifica i riferimenti (ad esempio alterando i record di un registrar DNS), pu\u00f2 dirottare un dominio intero su altri IP. Questo \u00e8 successo, ad esempio, in attacchi a provider DNS o in scenari di censura statale (dove i resolver ISP sono modificati per restituire IP \u201cfake\u201d per certi domini). Contromisure includono l\u2019uso di registrar con protezioni robuste (2FA, lock) e monitoraggio continuo dei record DNS critici.<\/p>\n\n\n\n<p><strong>Best practice relative al DNS<\/strong> per un responsabile alla sicurezza includono: utilizzare resolver DNS ricorsivi sicuri (magari in-house o servizi con filtro malware), abilitare DNSSEC validation sui resolver interni per i propri utenti, implementare DNSSEC per i domini gestiti dall\u2019organizzazione in modo da prevenire impersonificazioni, isolare e proteggere i server DNS autoritativi (pochi servizi devono contattarli, quindi regole firewall restrittive e monitoraggio). Inoltre, configurare correttamente i record per proteggere email e servizi (DNS \u00e8 utilizzato in meccanismi di sicurezza come SPF, DKIM, DMARC per l\u2019email authentication). Un altro aspetto \u00e8 la privacy: le query DNS tradizionali sono in chiaro, quindi un attaccante che sniffa la rete vede tutti i nomi richiesti (che possono rivelare i siti visitati, ecc.). In risposta, si stanno diffondendo protocolli come <strong>DNS over HTTPS (DoH)<\/strong> o <strong>DNS over TLS (DoT)<\/strong> che cifrano il traffico DNS tra client e resolver. Questo migliora la riservatezza, ma pone sfide per i controlli aziendali (non si pu\u00f2 pi\u00f9 facilmente ispezionare il contenuto DNS). Un coordinatore dovr\u00e0 quindi bilanciare privacy e capacit\u00e0 di monitoraggio, magari attivando DoT\/DoH con server fidati ma anche usando sistemi di <em>split-horizon DNS<\/em> per risolvere internamente i nomi aziendali e avere visibilit\u00e0.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>BGP (Border Gateway Protocol)<\/strong><\/p>\n\n\n\n<p><strong>BGP<\/strong> \u00e8 il protocollo di routing globale che tiene unita Internet. Mentre protocolli come OSPF, EIGRP, IS-IS gestiscono il routing <em>interno<\/em> a una singola organizzazione o sistema autonomo (IGP \u2013 Interior Gateway Protocols), BGP \u00e8 l\u2019<strong>Exterior Gateway Protocol<\/strong> che connette tra loro i diversi <em>Autonomous System (AS)<\/em> \u2013 essenzialmente le reti di propriet\u00e0 di fornitori di connettivit\u00e0 (ISP, dorsali, grandi organizzazioni) identificate da un numero AS univoco. In parole semplici, BGP \u00e8 il metodo con cui le reti annunciano ad altre reti quali prefissi IP possono raggiungere attraverso di loro, permettendo cos\u00ec di instradare pacchetti da un capo all\u2019altro del mondo, passando per molte reti intermedie. BGP \u00e8 dunque il \u201c<strong>sistema di comunicazione tra router di confine<\/strong>\u201d che consente a Internet di funzionare come un\u2019unica grande rete. Senza BGP, i pacchetti oltre la propria rete locale non saprebbero dove andare.<\/p>\n\n\n\n<p>Dal punto di vista tecnico, BGP \u00e8 un protocollo di routing di tipo <em>path-vector<\/em>: ogni annuncio BGP informa su un prefisso IP raggiungibile e include l\u2019<em>AS-PATH<\/em>, ovvero la sequenza di AS che bisogna attraversare per raggiungere quel prefisso. I router BGP (detti spesso <em>Route Reflector<\/em> o <em>router di bordo<\/em>) scambiano messaggi su <strong>connessioni TCP (porta 179)<\/strong>. BGP \u00e8 incrementale: invece di scambiare periodicamente l\u2019intera tabella come alcuni IGP, dopo l\u2019iniziale <em>full routing table exchange<\/em>, invia solo aggiornamenti quando cambia qualcosa (annuncio di nuova rotta o ritiro di una esistente). Questo lo rende scalabile per Internet dove esistono oltre 900k prefissi IPv4 annunciati. BGP permette politiche: ogni operatore pu\u00f2 definire preferenze su quali rotte usare o annunciare (ad esempio preferire percorsi pi\u00f9 corti in termini di AS-PATH, o quelli ricevuti da clienti su quelli ricevuti da provider per motivi economici).<\/p>\n\n\n\n<p><strong>Vulnerabilit\u00e0 e incidenti BGP<\/strong>: BGP si basa in gran parte sulla fiducia tra operatori e fino a tempi recenti non incorporava meccanismi crittografici robusti. Ci\u00f2 lo rende vulnerabile al cosiddetto <strong>BGP hijacking<\/strong>: un AS malevolo (o mal configurato) pu\u00f2 annunciare rotte per prefissi IP che non gli appartengono, deviando il traffico. Ad esempio, nel 2008 l\u2019annuncio errato di una rotta per YouTube da parte di un ISP pakistano (nel tentativo di censurare YouTube localmente) propag\u00f2 a livello globale, rendendo YouTube irraggiungibile per ore. In altri casi, attori malevoli hanno annunciato prefissi bancari o di criptovalute per intercettare dati. BGP hijack pu\u00f2 portare a <strong>interruzione<\/strong> (se il traffico viene in un vicolo cieco) o <strong>Man-in-the-Middle<\/strong> (se il traffic hijacker lo inoltra verso la destinazione vera dopo averlo intercettato). Secondo analisi recenti, essendo BGP una tecnologia con ~35 anni di et\u00e0, \u00e8 \u201cfacile da manipolare per reinstradare il traffico Internet o addirittura isolare intere regioni\u201d. Infatti, casi documentati mostrano come in situazioni geopolitiche (es. crisi Crimea\/Ucraina), BGP sia stato usato intenzionalmente per deviare traffico di intere aree verso infrastrutture sotto controllo di governi, creando di fatto \u201cfrontiere digitali\u201d coerenti con quelle militari.<\/p>\n\n\n\n<p>Le contromisure emergenti sono: <strong>RPKI (Resource Public Key Infrastructure)<\/strong>, un sistema di certificati digitali che associa prefissi IP e numeri AS a enti legittimi, permettendo ai router di verificare se un certo AS \u00e8 autorizzato ad annunciare un certo prefisso. Implementare RPKI e filtri di validazione (droppare annunci BGP non validati) riduce i rischi di hijack accidentali e rende pi\u00f9 difficile quelli malevoli (che richiederebbero compromissione dei certificati). Inoltre, buone pratiche come i filtri <strong>BCP 38<\/strong> anti-spoofing e l\u2019obbligo per gli ISP di filtrare annunci in ingresso da clienti che non corrispondono ai loro IP (route filtering) riducono la superficie di attacco. In ambito di sicurezza nazionale, \u00e8 auspicabile una stretta collaborazione con gli operatori di rete per assicurare che tali misure siano adottate, dato che un attacco BGP pu\u00f2 essere usato anche come vettore per isolare un paese o spostare traffico attraverso nodi di sorveglianza (si pensi a un hijack temporaneo che dirotta traffico europeo via AS in un altro continente per spiarlo, poi lo rilascia verso la destinazione \u2013 tattica rilevata in alcune analisi di routing).<\/p>\n\n\n\n<p>Un altro rischio BGP \u00e8 l\u2019<strong>instabilit\u00e0 o errore di configurazione<\/strong>: BGP \u00e8 complesso ed errori nelle politiche possono causare <em>route leak<\/em> (annuncio di rotte ricevute da un provider verso un altro provider quando non dovrebbe, saturando percorsi imprevisti) o <em>flapping<\/em> (rotte che oscillano ripetutamente su\/gi\u00f9 causando overhead). Questi incidenti possono avere impatti collaterali di sicurezza: un route leak pu\u00f2 congestionare link inattesi, rallentando comunicazioni critiche o firewall, oppure un flapping eccessivo potrebbe stressare i router fino a farli riavviare per carico (causando DoS su interi segmenti di rete).<\/p>\n\n\n\n<p><strong>Ruolo del responsabile della sicurezza su BGP<\/strong>: per un\u2019organizzazione che potrebbe gestire proprie infrastrutture di rete, \u00e8 cruciale avere visibilit\u00e0 BGP. Ci\u00f2 include utilizzare servizi di monitoring (es. RouteViews, RIPE Atlas) che avvisino se i prefissi dell\u2019organizzazione vengono annunciati da AS esterni (potenziale hijack in corso) o se route importanti spariscono. In caso di incidente BGP, il responsabile deve saper interfacciarsi con i <em>Network Operator Groups<\/em> e CERT\/CSIRT di settore per coordinare una risposta (ad esempio, diffondere rapidamente la notizia di non accettare annunci da AS X, o contattare l\u2019operatore responsabile dell\u2019annuncio spurio).<\/p>\n\n\n\n<p>Inoltre, la comprensione di BGP \u00e8 importante per valutare la resilienza delle comunicazioni critiche: per servizi governativi essenziali, ci si pu\u00f2 assicurare multihoming (connessione a pi\u00f9 ISP con diverse rotte) e preferire percorsi che minimizzino passaggi in zone a rischio. Ad esempio, se un paese teme spionaggio, potrebbe voler monitorare se il suo traffico passa per AS di altri paesi non amici e magari accordarsi con gli ISP per restrizione di routing. Strumenti di tracciamento (traceroute a livello AS) aiutano a mappare i percorsi.<\/p>\n\n\n\n<p>Riassumendo, BGP \u00e8 un protocollo potente ma datato, <strong>core di Internet<\/strong> e allo stesso tempo <strong>punto debole<\/strong> sfruttabile. Lo sforzo collettivo di mettere in sicurezza BGP (attraverso RPKI, monitoring e cooperazione tra ISP) \u00e8 in corso e i professionisti di sicurezza devono essere partecipi: conoscere gli incidenti storici, sostenere l\u2019adozione di misure protettive e includere scenari di attacco BGP nei propri piani di rischio (specialmente in contesti di infrastrutture critiche dove un attacco di routing pu\u00f2 significare blackout comunicativo).<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-42833c11e3594cf15bf4f315d01f7135\"><strong>Reti di elaboratori (Modello OSI)<\/strong><\/p>\n\n\n\n<div class=\"wp-block-group is-nowrap is-layout-flex wp-container-core-group-is-layout-ad2f72ca wp-block-group-is-layout-flex\">\n<p>Il <strong>modello OSI (Open Systems Interconnection)<\/strong> \u00e8 un modello di riferimento concettuale, proposto dall\u2019ISO (<a href=\"https:\/\/www.iso.org\/\" target=\"_blank\" rel=\"noreferrer noopener\">International Organization for Standardization<\/a>), che suddivide le funzioni di rete in <strong>sette livelli <\/strong>astratti. Anche se Internet pratica quotidiana segue pi\u00f9 da vicino il modello TCP\/IP a 4-5 livelli, l\u2019OSI rimane uno schema didattico e progettuale prezioso: fornisce un linguaggio comune per descrivere dove si collocano protocolli e apparecchiature e come le diverse parti di una comunicazione interagiscono. I sette livelli del modello OSI, dal pi\u00f9 basso (fisico) al pi\u00f9 alto (applicazione), sono i seguenti:<\/p>\n<\/div>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"623\" height=\"780\" src=\"https:\/\/www.fabriziogiancola.eu\/wp-content\/uploads\/2025\/08\/Screenshot-2024-09-23-150831.png\" alt=\"\" class=\"wp-image-2267\" srcset=\"https:\/\/www.fabriziogiancola.eu\/wp-content\/uploads\/2025\/08\/Screenshot-2024-09-23-150831.png 623w, https:\/\/www.fabriziogiancola.eu\/wp-content\/uploads\/2025\/08\/Screenshot-2024-09-23-150831-240x300.png 240w\" sizes=\"auto, (max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 984px) 61vw, (max-width: 1362px) 45vw, 600px\" \/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Livello 1: Fisico<\/strong>. Si occupa della trasmissione dei bit grezzi sul mezzo fisico di comunicazione. Definisce specifiche elettriche, meccaniche e funzionali per attivare, mantenere e disattivare collegamenti fisici. Ad esempio, stabilisce che forma d\u2019onda e tensione rappresentano un \u201c1\u201d o uno \u201c0\u201d, il tipo di connettore e cavo (rame, fibra ottica), la modulazione usata in trasmissioni wireless, la sincronizzazione dei bit, etc.. Dispositivi tipici al livello fisico sono i <strong>repeater<\/strong>, gli <strong>hub <\/strong>Ethernet (che rigenerano il segnale su pi\u00f9 porte) e i componenti come cavi, transceiver, antenne. Dal punto di vista della sicurezza, il livello fisico \u00e8 spesso trascurato ma non privo di rischi: <em>tapping <\/em>su cavi (intercettazioni fisiche), interferenze elettromagnetiche intenzionali o accidentali e attacchi di <em>jamming <\/em>nel wireless (disturbo radio per negare il servizio) sono minacce di livello 1. Contromisure includono cablaggi schermati, monitoraggio di link (per rilevare disconnessioni o anomalie elettriche) e in ambienti critici l\u2019uso di fibre ottiche (difficili da intercettare senza provocare perdite di segnale rilevabili).<\/li>\n\n\n\n<li><strong>Livello 2: Collegamento Dati<\/strong>. Fornisce il trasferimento dei dati tra due nodi adiacenti (collegati dallo stesso mezzo fisico) in modo affidabile, strutturando i bit in <strong>frame<\/strong> e implementando controlli di errore e controllo di flusso su ciascun collegamento. Qui troviamo protocolli come <strong>Ethernet (IEEE 802.3)<\/strong> per le LAN cablate, <strong>Wi-Fi (IEEE 802.11)<\/strong> per le LAN wireless, <strong>PPP<\/strong> per collegamenti punto-punto, <strong>HDLC<\/strong>, ecc. Il livello 2 utilizza <strong>indirizzi fisici<\/strong> (<strong>MAC address<\/strong> per Ethernet) per identificare le schede di rete sorgenti e destinazione su un segmento. Funzioni chiave includono l\u2019<strong>error detection<\/strong> (es. CRC per individuare frame corrotti e scartarli) e a volte l\u2019<strong>error recovery<\/strong> (es. in collegamenti PPP pu\u00f2 esserci ritrasmissione). <strong>Switch<\/strong> e <strong>bridge<\/strong> operano a questo livello, instradando frame in base agli indirizzi MAC e segmentando <em>collision domains<\/em>. Dal punto di vista sicurezza, il livello data link presenta minacce come <strong>MAC flooding<\/strong> (in cui un attaccante inonda lo switch di frame con MAC fittizi, saturando la CAM table e facendolo passare in modalit\u00e0 hub, favorendo sniffing), <strong>spoofing di MAC<\/strong> (un dispositivo assume l\u2019identit\u00e0 MAC di un altro, magari per bypassare filtri MAC ACL o dirottare traffico destinato al legittimo) e attacchi specifici di tecnologie: ad esempio, <strong>ARP poisoning<\/strong> (avvelenamento cache ARP) sfrutta il protocollo di risoluzione indirizzi (tra livello 2 e 3) per associare un MAC dell\u2019attaccante all\u2019IP della vittima, di fatto intercettando il traffico locale. Strumenti come <strong>ettercap<\/strong> facilitano questo attacco, che pu\u00f2 essere mitigato con tecniche come ARP statici o protocolli di sicurezza come <em>DHCP Snooping<\/em> e <em>Dynamic ARP Inspection<\/em> sugli switch gestiti. Sul Wi-Fi, il livello 2 \u00e8 dove operano misure di cifratura come <strong>WPA2\/WPA3<\/strong>: la protezione delle trame radio con cifre come AES-CCMP avviene qui. Dunque, la robustezza del livello 2 wireless (chiavi forti, autenticazione 802.1X con EAP, ecc.) \u00e8 essenziale contro sniffing e accessi non autorizzati.<\/li>\n\n\n\n<li><strong>Livello 3: Rete.<\/strong> \u00c8 responsabile dell\u2019instradamento (routing) dei pacchetti attraverso reti diverse, dal mittente finale al destinatario finale, potenzialmente passando per pi\u00f9 nodi di commutazione (router). Il livello 3 introduce gli <strong>indirizzi logici<\/strong> (es. indirizzi IP) e si occupa di trovare percorsi e di gestire la congestione a livello di pacchetto. <strong>IP<\/strong> (Internet Protocol) \u00e8 il protagonista (versione 4 e 6) a questo livello. Altri esempi includono protocolli legacy o specializzati come IPX, AppleTalk (quasi obsoleti) e protocolli di routing come <strong>ICMP<\/strong> potrebbe essere considerato tra 3 e 4 (di supporto al funzionamento di IP, es. con ping ed error message). I <strong>router<\/strong> operano al livello 3, guardando l\u2019indirizzo di destinazione nei pacchetti IP e inoltrandoli secondo la routing table. La sicurezza a livello 3 coinvolge diversi aspetti: <strong>controllo degli accessi IP<\/strong> (liste di controllo accessi su router e firewall che permettono o bloccano traffico in base a IP sorgente\/dest, protocollo e porta \u2013 bench\u00e9 la porta sia L4), protezione dell\u2019integrit\u00e0 dei pacchetti (qui agisce ad esempio <strong>IPsec AH\/ESP<\/strong> che aggiunge firma o cifratura a livello IP) e la robustezza contro attacchi di scansione e DoS basati su IP (ping of death, fragmentation attacks). Un amministratore deve implementare <em>filtering<\/em> appropriato (ad esempio: filtrare pacchetti in ingresso con IP sorgenti privati o palesemente spoofati \u2013 BCP 38, ingress filtering; bloccare protocolli non necessari come IPv6 se non in uso, o ICMP solo in modo controllato perch\u00e9 ICMP \u00e8 utile per la diagnostica ma pu\u00f2 essere abusato in tunneling o scansioni). Anche gli attacchi di <strong>tracciamento <\/strong>(es. <em>traceroute<\/em> abusato per mappare la rete) lavorano su livello 3\/4 usando TTL manipolato; un SOC potrebbe rilevare e allertare se vede traceroute verso host interni, segno di ricognizione. In sintesi, il livello rete \u00e8 dove si definiscono i confini della <em>security perimeter<\/em>: definire quali IP o segmenti possono comunicare, implementare segmentazione della rete (VLAN e routing intervlan con ACL) e applicare tecniche come <em>network address translation (NAT)<\/em> \u2013 che pur essendo nata per risparmiare IPv4, fornisce un effetto collaterale di mascheramento degli IP interni, aggiungendo oscurit\u00e0 verso l\u2019esterno.<\/li>\n\n\n\n<li><strong>Livello 4: Trasporto<\/strong>. Offre comunicazione end-to-end affidabile o non affidabile tra processi applicativi su host differenti. Due protocolli cardine qui sono <strong>TCP<\/strong> (orientato alla connessione, affidabile, con controllo di flusso) e <strong>UDP<\/strong> (datagrammi non connessi, non garantiti). Il livello trasporto identifica anche le <strong>porte <\/strong>(numeri che distinguono i flussi applicativi: es. porta 80 per HTTP su TCP, 53 per DNS su UDP, ecc.), permettendo la <strong>multiplexing <\/strong>di pi\u00f9 conversazioni sulla stessa connessione di rete. Qui troviamo anche concetti come <em>segmento <\/em>(TCP segment) o <em>datagramma <\/em>(UDP). Dal punto di vista sicurezza, sul livello 4 agiscono molti controlli nei firewall <strong>stateful<\/strong>, che monitorano lo stato delle connessioni TCP e possono bloccare tentativi anomali (ad esempio pacchetti TCP non appartenenti ad alcuna connessione nota). Il <strong>port scanning<\/strong> \u00e8 una tecnica di ricognizione di livello 4: un attaccante invia tentativi di connessione su varie porte per scoprire quali servizi sono attivi; strumenti come <em>nmap<\/em> variano i tipi di pacchetto (SYN scan, ACK scan, UDP scan) per inferire regole firewall e servizi. Un analista deve saper interpretare log come \u201cDropped packet from X to Y: TCP flags SYN\u201d e capire che \u00e8 uno scan. Inoltre, <strong>attacchi DDoS<\/strong> spesso si manifestano su questo livello: SYN flood (gi\u00e0 descritto), o saturazione di porte specifiche (es. attacco a un server web saturando la porta 80 con richieste incomplete). Difese includono meccanismi antidos sui firewall e anche a livello di sistema operativo (stack TCP robusti con backlog di connessioni ampia, cookies, ecc.). I protocolli di trasporto hanno anche implicazioni su performance e perci\u00f2 su rilevamento anomalie: es. un flusso TCP legittimo ha una certa sincronia tra pacchetti e ack; se un flusso esce dalle statistiche usuali (troppi RST, troppi ritrasmissioni) potrebbe indicare un problema o un attacco in corso di blocco. A livello trasporto si implementa anche la <strong>sicurezza delle sessioni<\/strong> in alcuni casi: per es., <strong>TLS <\/strong>(il protocollo usato per HTTPS) in realt\u00e0 risiede sopra TCP (livello 5 OSI se consideriamo session\/present, o direttamente come parte dell\u2019applicazione), ma concettualmente fornisce sicurezza a ci\u00f2 che il trasporto trasmette. In un contesto OSI, potremmo dire che l\u2019inizio handshake TLS \u00e8 livello 5 sessione (instaura un canale) e la cifratura\/decifratura \u00e8 presentazione (livello 6). Comunque, il responsabile di sicurezza deve sapere che firewall di nuova generazione possono operare fino al livello 7, ma spesso regole efficaci si definiscono su combinazioni di criteri L3\/L4 (IP\/porta) per bloccare accessi a servizi indesiderati o limitare provenienze.<\/li>\n\n\n\n<li><strong>Livello 5: Sessione<\/strong>. Fornisce i meccanismi per controllare il dialogo tra due applicazioni, istituendo, gestendo e terminando <strong>sessioni di comunicazione<\/strong>. Una sessione \u00e8 essenzialmente una comunicazione logica di lunga durata tra due entit\u00e0, che pu\u00f2 comprendere pi\u00f9 scambi di dati. Funzioni tipiche del livello di sessione includono la <strong>gestione delle connessioni<\/strong> (apertura, autenticazione al livello di sessione, chiusura ordinata) e <strong>controllo del dialogo<\/strong> (chi pu\u00f2 inviare in un dato momento, half-duplex vs full-duplex, sincronizzazione di checkpoint per riprendere trasferimenti interrotti). Nella pratica di Internet, il livello sessione non \u00e8 molto distinto: protocolli come TLS\/SSL possono essere visti come aggiungere una sessione sicura su TCP, o protocolli come NetBIOS session, RPC, PPTP ecc. definiscono sessioni sopra il trasporto. Dal punto di vista sicurezza, qui collochiamo concetti come <strong>autenticazione della sessione<\/strong> (per es., in TLS un client e server si autenticano e stabiliscono una sessione cifrata con ID di sessione), oppure <strong>gestione delle sessioni applicative<\/strong> (ad esempio i token di sessione HTTP per tenere traccia di un utente loggato su un sito \u2013 concettualmente livello 5\/7). Le minacce includono il <strong>dirottamento di sessione (session hijacking)<\/strong>, in cui un attaccante subentra in una sessione attiva rubando credenziali di sessione (es. cookie di autenticazione web non protetto) o per difetti del protocollo (un esempio storico: nel protocollo PPTP VPN c\u2019erano weakness che permettevano di desincronizzare e prendere controllo della sessione). Un altro concetto di sessione \u00e8 nel checkpointing: alcuni protocolli di trasferimento file lunghi implementano marker di sincronizzazione (per non ricominciare da capo se la sessione cade). Un attaccante potrebbe abusare del meccanismo di ripresa (resumption) se non ben protetto, per forzare trasferimenti incompleti o inserire dati. In contesti moderni, molti di questi dettagli sessione sono integrati nelle applicazioni (livello 7), quindi il livello 5 OSI \u00e8 spesso citato in teoria pi\u00f9 che implementato separatamente. Il coordinatore di sicurezza comunque deve assicurarsi che le sessioni, qualunque sia il contesto, siano protette: ad esempio, nelle applicazioni web la gestione sicura dei token di sessione (randomici, con scadenza, marcati HttpOnly e Secure se cookie) \u00e8 cruciale per prevenire impersonificazione.<\/li>\n\n\n\n<li><strong>Livello 6: Presentazione<\/strong>. Si occupa della sintassi e semantica dei dati scambiati tra applicazioni. In pratica, fornisce trasformazioni di dati che permettono a sistemi con convenzioni diverse di comunicare. Ci\u00f2 include <strong>conversioni di formato<\/strong> (esempio: codifica dei caratteri \u2013 convertire testo Unicode in ASCII se il destinatario supporta solo quello), <strong>serializzazione <\/strong>di strutture complesse in un formato standard (tipo JSON, XML, ASN.1), <strong>compressione <\/strong>(per ridurre la mole di dati da trasmettere) e <strong>cifratura <\/strong>per garantire confidenzialit\u00e0. Il livello di presentazione \u00e8 quindi dove i dati grezzi dell\u2019applicazione vengono preparati per la trasmissione e viceversa all\u2019arrivo vengono rielaborati in forma utilizzabile dall\u2019app. Un esempio concreto: in una connessione HTTPS, il contenuto HTTP vero e proprio viene cifrato a livello presentazione (TLS) e poi passato come flusso cifrato al livello trasporto (TCP) per l\u2019invio. Nella sicurezza informatica, il livello 6 \u00e8 cruciale perch\u00e9 \u00e8 dove avvengono <strong>crittografia\/decrittografia<\/strong> e <strong>codifiche<\/strong>. Ad esempio, molti attacchi web come XSS, SQLi, ecc., sfruttano mancate conversioni di formato (un input utente che andava interpretato solo come testo viene invece eseguito come codice). Una robusta \u201cpresentazione\u201d in un\u2019applicazione web significa <em>escaping <\/em>appropriato di caratteri speciali quando dati non fidati vengono inseriti in HTML, SQL, XML, ecc., per prevenire l\u2019esecuzione indesiderata \u2013 in altri termini, difese come <strong>output encoding<\/strong> per XSS o <strong>query parametrizzate<\/strong> (che separano i dati dalla sintassi SQL) attengono a questo concetto. Dal punto di vista delle comunicazioni di rete, standard come <strong>TLS <\/strong>garantiscono che i dati in presentazione siano cifrati end-to-end: un responsabile deve assicurarsi che i servizi critici usino protocolli sicuri (es. preferire FTPS\/SFTP a FTP in chiaro, HTTPS a HTTP, SSH a Telnet, ecc.) cosicch\u00e9 anche se il traffico viene intercettato a livello inferiore, risulti incomprensibile. Inoltre, il livello presentazione include la gestione di <strong>certificati digitali<\/strong> e formati di scambio: competenze in PKI e negoziazione di protocolli (quali ciphersuite TLS sono consentite, usi di TLS 1.3 vs deprecazione di SSLv3\/TLS1.0 insicuri) rientrano tra quelle richieste a un esperto di sicurezza per garantire che i dati \u201cpresentati\u201d in rete siano sempre protetti secondo lo stato dell\u2019arte.<\/li>\n\n\n\n<li><strong>Livello 7: Applicazione<\/strong>. \u00c8 il livello pi\u00f9 alto, quello con cui interagiscono direttamente le applicazioni software e, in ultima analisi, l\u2019utente finale. Fornisce quindi i servizi di rete pi\u00f9 vicini all\u2019utilizzatore: protocolli di <strong>posta elettronica<\/strong> (SMTP per inviare, IMAP\/POP3 per ricevere), <strong>web <\/strong>(HTTP\/HTTPS), <strong>trasferimento file<\/strong> (FTP, SFTP), <strong>servizi directory<\/strong> (LDAP), <strong>accesso remoto<\/strong> (SSH, Telnet) e molti altri servizi specializzati (DNS stesso \u00e8 considerato applicazione nel modello OSI, cos\u00ec come protocolli voce su IP come SIP\/VoIP, etc.). Al livello applicazione si definiscono i formati dei messaggi di alto livello e le procedure di scambio specifiche di quello <em>use case<\/em>. Ad esempio, HTTP definisce come un client pu\u00f2 richiedere una risorsa con un verbo (GET, POST, etc.) e come un server risponde con un codice di stato e eventuale contenuto; SMTP definisce i comandi per trasmettere email tra server; SSH definisce come incapsulare un terminale remoto sicuro. Dal punto di vista sicurezza, il livello applicazione \u00e8 dove tipicamente risiedono le <strong>vulnerabilit\u00e0 logiche<\/strong> e <strong>di input<\/strong> pi\u00f9 complesse: injection, buffer overflow applicativi, deserializzazione insicura, autenticazione debole, autorizzazioni errate e cos\u00ec via (molte delle categorie OWASP Top 10 per applicazioni web sono questioni di livello 7). Un responsabile per gli incidenti deve avere familiarit\u00e0 con i protocolli applicativi per riconoscere anomalie: es. traffico HTTP verso un server web che contiene comandi sospetti ( <code>\/admin\/delete.php?id=1;DROP TABLE users<\/code>) potrebbe indicare un attacco SQLi; oppure richieste LDAP malformate potrebbero segnalare un tentativo di exploit di Active Directory. Anche la <strong>modellazione delle minacce<\/strong> avviene in gran parte a livello applicazione: qui si chiede \u201ccosa succede se un utente malintenzionato invia dati oltre i limiti?\u201d, \u201ccosa se effettua sequenze di API fuori ordine?\u201d, etc. Ogni protocollo ha le sue particolarit\u00e0: FTP ad esempio espone credenziali in chiaro se non \u00e8 protetto e inoltre utilizza porte dinamiche (che i firewall devono gestire in modo speciale, con moduli helper, altrimenti pu\u00f2 essere abusato per bypassare porte); SMTP pu\u00f2 essere sfruttato per relay non autorizzati se non configurato bene (open relay) e per diffondere phishing\/malware; HTTP \u00e8 il veicolo di tantissimi attacchi, dai malware via download, al phishing via siti clone, fino alle exploit di librerie web.<\/li>\n<\/ul>\n\n\n\n<p>Ai fini di prevenzione e gestione degli incidenti, \u00e8 utile dotarsi di strumenti di <em>Application Layer Security<\/em>: <strong>WAF <\/strong>(Web Application Firewall) per analizzare il traffico HTTP e bloccare pattern malevoli noti (anche se non sostituisce il secure coding, \u00e8 un utile layer difensivo), <strong>antivirus\/antimalware gateway<\/strong> per controllare file trasferiti via protocolli applicativi (es. scanner SMTP per allegati email, o proxy HTTP con antimalware integrato) e sistemi di <strong>Data Loss Prevention (DLP)<\/strong> che analizzino il contenuto applicativo in uscita (es. per individuare stringhe che sembrano numeri di carta di credito o dati classificati e bloccarne l\u2019esfiltrazione via email\/web). Inoltre, la <strong>telemetria di livello 7<\/strong> (log applicativi) \u00e8 fondamentale in fase di risposta: i log di un server web (es. access log di Apache\/Nginx) possono mostrare un pattern di exploit (decine di tentativi di accedere a <code>wp-admin.php<\/code> indicano un bot che cerca di violare WordPress), i log di un database possono mostrare query strane (tentativi di selezionare tabelle di sistema da un\u2019app che non dovrebbe), i log di un server DNS possono indicare tunneling come detto. Un SOC ben organizzato correla eventi su pi\u00f9 livelli: ad esempio, un alert IDS su un payload sospetto a livello 4+7 (un pacchetto TCP con dentro un comando SQL anomalo) incrociato con un log applicativo di errore database pu\u00f2 confermare un tentativo di SQL injection riuscito o meno.<\/p>\n\n\n\n<p><strong>Integrazione e concetti trasversali<\/strong>: Una cosa importante da capire \u00e8 che i livelli non sono completamente isolati: ogni livello aggiunge il suo overhead e le sue vulnerabilit\u00e0 possono propagarsi. Ad esempio, un attacco DDoS a livello 7 (come HTTP Flood, numerosissime richieste web) sfrutta comunque la connessione TCP sottostante: mitigarlo pu\u00f2 richiedere azioni a livello 7 (rispondere con CAPTCHA, tarpit) ma anche a livello 4 (limitare connessioni per IP) e livello 3 (filtrare IP noti malevoli). Oppure, una falla a livello 2 come ARP poisoning pu\u00f2 portare a <em>Man-in-the-Middle<\/em> che intercetta e poi manipola dati di livello 7 (inserendo script malevoli nel traffico web, se questo non \u00e8 cifrato). Conoscere l\u2019OSI aiuta a <strong>compartimentalizzare <\/strong>i problemi e a parlare con gli specialisti giusti: ad esempio, se si riscontra che \u201cle email non arrivano a destinazione\u201d, potrebbe essere un problema di livello 7 (misconfigurazione SMTP, o bloccate per contenuti), livello 3 (routing verso il mail server errato) o altro; il modello OSI offre un approccio per isolare: <em>ping <\/em>(L3), <em>telnet porta<\/em> 25 (L4), analisi logs SMTP (L7) e cos\u00ec via. Nella risoluzione di incidenti, spesso si \u201crisale la pila OSI\u201d per individuare dove esattamente risiede il fault o l\u2019attacco.<\/p>\n\n\n\n<p>In conclusione, il modello OSI con i suoi 7 livelli \u2013 <strong>Fisico, Collegamento dati, Rete, Trasporto, Sessione, Presentazione, Applicazione<\/strong> \u2013 \u00e8 uno strumento concettuale che aiuta a progettare, proteggere e diagnosticare le reti di calcolatori. Ogni livello introduce considerazioni di sicurezza specifiche e un <em>responsabile per la sicurezza informatica<\/em> deve averne padronanza per implementare una strategia di difesa in profondit\u00e0: multiple protezioni sovrapposte attraverso la pila, cosicch\u00e9 anche se un attacco aggira un livello (es. malware che viaggia cifrato su HTTPs \u2013 invisibile al firewall L7), venga intercettato a un altro (es. analisi comportamentale al livello applicazione endpoint, o decrittazione in un proxy per l\u2019ispezione). Lo standard ISO\/OSI stesso, pur teorico, ha generato protocolli e influenzato architetture \u2013 conoscere ad esempio che <em>X.509<\/em> (certificati) nasce da standard OSI di presentazione, o che <em>LDAP <\/em>\u00e8 figlio di X.500 (applicazione OSI), arricchisce la comprensione storica e pratica che torna utile quando si incrociano sistemi eterogenei (ad es. integrazione di vecchi sistemi mainframe o SCADA che a<br>volte ancora usano stack particolari).<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-124cf309493fffd8f0df3581e469a8a4\"><strong>Fondamenti di algoritmi<\/strong><\/p>\n\n\n\n<p>Un <strong>algoritmo <\/strong>\u00e8 una procedura definita, costituita da una sequenza finita di istruzioni, che risolve un problema o svolge un determinato compito. In informatica, gli algoritmi rappresentano le ricette operative per qualsiasi programma: dal semplice calcolo di una somma alla crittografia avanzata, tutto si riduce a passi elementari che il calcolatore esegue. Formalmente, si richiede che un algoritmo abbia alcune propriet\u00e0: <strong>finitezza <\/strong>(deve terminare in un numero finito di passi), <strong>determinismo <\/strong>(stessi input producono stessi output, a meno di componenti aleatorie volute), <strong>non ambiguit\u00e0<\/strong> (ogni passo \u00e8 definito in modo univoco, interpretabile senza dubbio) e <strong>generalit\u00e0 <\/strong>(risolve una classe di problemi, non un solo caso specifico).<\/p>\n\n\n\n<p>Esempi di algoritmi classici includono: l\u2019algoritmo di ordinamento (ordinare una lista di numeri o stringhe \u2013 con varianti famose come QuickSort, MergeSort, HeapSort, etc.), algoritmi di ricerca (trovare un elemento in una collezione \u2013 es. ricerca lineare vs ricerca binaria in una lista ordinata), algoritmi di grafi (cammini minimi, visite in profondit\u00e0\/ampiezza, ecc.), algoritmi di ottimizzazione (zaino, percorso pi\u00f9 breve, flusso massimo) e tanti altri. Nella pratica quotidiana, un professionista di sicurezza pu\u00f2 incontrare algoritmi ad esempio nell\u2019analisi di performance di un sistema (sapere se una certa operazione \u00e8 O(n) lineare o O(n^2) quadratica aiuta a capire se un attacco di stress potrebbe causare rallentamenti significativi), oppure nella comprensione di meccanismi crittografici (dove la solidit\u00e0 di un algoritmo di cifratura spesso si basa su problemi computazionalmente difficili, come la fattorizzazione dei grandi numeri primi per RSA).<\/p>\n\n\n\n<p><strong>Complessit\u00e0 computazionale<\/strong>: uno degli aspetti fondamentali nello studio degli algoritmi \u00e8 la loro <strong>complessit\u00e0<\/strong>, cio\u00e8 la quantit\u00e0 di risorse (tempo di calcolo, spazio di memoria) che richiedono in funzione della dimensione dell\u2019input. La complessit\u00e0 in termini di tempo viene di norma espressa tramite la <em>notazione O-grande<\/em>, che fornisce un limite superiore asintotico sulla crescita del costo computazionale al crescere di n (taglia input). Ad esempio, dire che un algoritmo \u00e8 O(n log n) significa che per gestire input pi\u00f9 grandi, il suo tempo cresce proporzionalmente a <em>n log n<\/em>. In generale, classifichiamo le complessit\u00e0 asintotiche in classi come: <strong>costante<\/strong> O(1), <strong>logaritmica <\/strong>O(log n), <strong>lineare <\/strong>O(n), <strong>quasi-lineare<\/strong> O(n log n), <strong>quadratica <\/strong>O(n^2), <strong>cubic <\/strong>O(n^3), \u2026<strong>esponenziale  <\/strong>O(2^n) e oltre. Chiaramente, algoritmi pi\u00f9 efficienti sono preferibili \u2013 un problema risolvibile con un algoritmo O(n) sar\u00e0 gestibile per input grandi molto meglio di uno O(n^2). Per contestualizzare: in un attacco di forza bruta, provare tutte le combinazioni di una password di lunghezza n pu\u00f2 essere ~O(k^n) (esponenziale nel numero di caratteri se ogni posizione ha k possibilit\u00e0), il che spiega perch\u00e9 aumentando lunghezza e complessit\u00e0 delle password la ricerca esaustiva diventa impraticabile.<\/p>\n\n\n\n<p>Per un <strong>responsabile alla sicurezza<\/strong>, la teoria degli algoritmi ha ricadute pratiche. Un esempio evidente \u00e8 nella crittografia: la sicurezza di molti algoritmi crittografici \u00e8 legata alla complessit\u00e0 computazionale di certi problemi. RSA, ECC, Diffie-Hellman si basano sul fatto che alcuni problemi (fattorizzazione di interi grandi, logaritmo discreto in certi gruppi) sembrano richiedere tempo esponenziale con i migliori algoritmi noti: quindi, con chiavi abbastanza lunghe, la brute force diventa impossibile nei tempi dell\u2019universo (a meno di progressi algoritmici o quantistici). Comprendere questo aiuta a scegliere parametri sicuri: ad esempio, sapere che il migliore algoritmo di fattorizzazione noto ha complessit\u00e0 sub-esponenziale (s\u00ec, c\u2019\u00e8 il <em>Number Field Sieve<\/em> che \u00e8 circa O(exp( (64\/9)^(1\/3) * (log n)^(1\/3) * (log log n)^(2\/3) )) ), consente ai crittografi di stimare quanti bit di RSA servono (oggi almeno 2048-bit) per resistere X anni. Un altro esempio: gli algoritmi di <em>hashing <\/em>(SHA-256, SHA-3) sono progettati per essere veloci da calcolare ma non invertibili senza provare molte possibilit\u00e0. La difficolt\u00e0 di trovare collisioni in SHA-256 \u00e8 legata a dover provare 2^128 operazioni (complessit\u00e0 bruteforce). Se un attaccante scoprisse un algoritmo molto migliore (es. O(2^64)), quell\u2019hash non sarebbe pi\u00f9 sicuro. Dunque, chi lavora in sicurezza deve seguire anche le scoperte nel mondo algoritmi (ad esempio, i recenti progressi su SHA-1 collisioni hanno reso questo hash deprecato). E ovviamente il <strong>calcolo quantistico<\/strong> promette di ridurre drasticamente la complessit\u00e0 di alcuni problemi: Shor\u2019s algorithm porta la fattorizzazione a complessit\u00e0 polinomiale, distruggendo RSA\/ECC una volta che avremo quantum computer abbastanza grandi.<\/p>\n\n\n\n<p>Al di l\u00e0 della crittografia, l\u2019analisi degli algoritmi \u00e8 utile per <strong>ottimizzare le difese e attacchi<\/strong>. Dal lato difensivo: un SIEM che raccoglie log deve avere algoritmi di correlazione efficienti, altrimenti con milioni di eventi generer\u00e0 ritardi \u2013 un buon coordinatore sa scegliere strumenti validi o architetture big data (es. utilizzare motori come Elasticsearch che usano algoritmi di ricerca efficaci). Dal lato offensivo: alcuni attacchi DoS sfruttano <em>algorithmic complexity attacks<\/em>, ad esempio l\u2019<strong>HashDoS<\/strong> (inviare tanti input calibrati per provocare collisioni in una tabella hash usata dall\u2019applicazione, degradando le look-up da O(1) a O(n) e bloccando il server) \u2013 questo fu dimostrato su Java, PHP e altri linguaggi, costringendo a migliorare gli algoritmi di hashing o introdurre randomizzazione. Un altro esempio sono i <strong>ReDoS<\/strong> (Regular Expression Denial of Service): usare input particolari per mandare in worst-case l\u2019algoritmo di matching delle espressioni regolari (che in alcuni engine pu\u00f2 diventare esponenziale). Questi sono attacchi sottili che richiedono comprensione di come un algoritmo risponde al worst-case. <\/p>\n\n\n\n<p><strong>Strutture dati e algoritmi<\/strong>: spesso insieme agli algoritmi si studiano le <strong>strutture dati<\/strong> (array, liste, pile, code, alberi, grafi, tabelle hash, ecc.), che influiscono sulle prestazioni. Una buona scelta di struttura pu\u00f2 prevenire inefficienze \u2013 es: cercare elementi duplicati in un array fa O(n^2) naive, ma usando una hash set diventa O(n) mediamente. Nella sicurezza software, questo significa anche prevenire vulnerabilit\u00e0 di prestazioni: se un input controllato dall\u2019utente potrebbe indurre il programma a usare un algoritmo quadratico, un attaccante pu\u00f2 sfruttarlo per rallentarlo. Ad esempio, generare intenzionalmente situazioni pessime (come l\u2019HashDoS citato). Dunque, parte del secure coding \u00e8 anche evitare costrutti algoritmicamente rischiosi o porre limiti (ad esempio, limitare lunghezza massima di input per evitare loop troppo lunghi).<\/p>\n\n\n\n<p><strong>P vs NP e problemi intrattabili<\/strong>: un concetto teorico ma con implicazioni \u00e8 la distinzione tra problemi in <strong>P<\/strong> (risolvibili in tempo polinomiale) e in <strong>NP<\/strong> (verificabili in polinomiale, ma non si conosce algoritmo polinomiale per risolverli). Molti problemi di ottimizzazione o ricerca combinatoria sono NP-difficili (come il <em>Traveling Salesman<\/em>, il <em>Subset Sum<\/em>, ecc.). Per la sicurezza, questo spiega perch\u00e9 certi obiettivi dell\u2019attaccante sono difficili: ad esempio, <em>craccare <\/em>un cifrario robusto equivale a cercare nello spazio delle chiavi (che cresce esponenzialmente col numero di bit). Oppure, un software antivirus che voglia decidere in generale se un programma \u00e8 malevolo va incontro al <em>problema della fermata<\/em> e questioni indecidibili; per questo gli antivirus usano euristiche imperfette \u2013 capire i limiti computazionali ci fa comprendere perch\u00e9 non esiste e probabilmente non esister\u00e0 mai \u201cl\u2019algoritmo perfetto\u201d per distinguere malware da software legittimo in ogni caso (problema indecidibile,  riducibile all\u2019halting problem). Quindi si lavora per euristiche (firma, comportamento) sapendo che esisteranno falsi negativi\/positivi.<\/p>\n\n\n\n<p><strong>Algoritmi distribuiti e fault tolerance<\/strong>: In un contesto come la sicurezza nazionale, con infrastrutture distribuite, \u00e8 importante conoscere anche gli algoritmi per <em>consenso distribuito<\/em> (es. Paxos, Raft) e per <em>gestione di guasti<\/em> \u2013 questi sono algoritmi non banali che garantiscono consistenza e disponibilit\u00e0 su pi\u00f9 nodi; la sicurezza di sistemi come blockchain, oppure di sistemi cluster per servizi critici, discende dalla solidit\u00e0 di tali algoritmi. Ad esempio, la robustezza di una blockchain dipende dall\u2019algoritmo di consenso (Proof of Work \u00e8 un \u201calgoritmo\u201d in senso lato con complessit\u00e0 regolata dalla difficolt\u00e0, BFT consensus ha tolleranza fino a f nodi corrotti se N &gt; 3f, ecc.).<\/p>\n\n\n\n<p>In sintesi, i fondamenti di algoritmi equipaggiano il professionista con un <strong>approccio analitico<\/strong> ai problemi: capire l\u2019ordine di grandezza di un attacco brute-force, valutare l\u2019impatto prestazionale di una misura di sicurezza (es. criptare tutto il traffico aggiunge overhead, ma di quanto?), scegliere strumenti in base alla scala (un SIEM con algoritmi subottimali funzioner\u00e0 su 1k eventi al secondo ma non su 100k eps). La <strong> <\/strong> \u00e8 quindi parte del bagaglio di un coordinatore, sebbene non debba implementare algoritmi da zero quotidianamente, deve saperne leggere i risultati e conversarci: ad esempio, comprendere un report che dice \u201cla complessit\u00e0 computazionale di rompere AES-256 \u00e8 di 2^254 operazioni, che con i mezzi attuali \u00e8 impraticabile\u201d oppure \u201cun attacco di tipo meet-in-the-middle riduce la complessit\u00e0 su 2DES da 2^112 a 2^57, ecco perch\u00e9 2DES non \u00e8 considerato sicuro\u201d. Senza basi sugli algoritmi, tali affermazioni sarebbero aride; con le basi, diventano guida all\u2019azione (passare direttamente ad AES o 3DES perch\u00e9 2DES \u00e8 debole, ecc.). Dunque la padronanza degli algoritmi e della loro complessit\u00e0 permette di <em>valutare rischi <\/em>in modo quantificabile e di <em>progettare contromisure<\/em> efficaci.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-dc548319578164feed5df4aa039fdfd2\"><strong>Linguaggi di programmazione (imperativi, di scripting, orientati agli oggetti)<\/strong><\/p>\n\n\n\n<p>I <strong>linguaggi di programmazione<\/strong> sono gli strumenti con cui vengono implementati gli algoritmi e le funzionalit\u00e0 software. Esistono centinaia di linguaggi, ma essi possono essere classificati per <em>paradigma<\/em> in base allo stile con cui si descrivono le istruzioni e i dati. In questa sezione ci focalizziamo su tre categorie importanti: linguaggi <strong>imperativi<\/strong>, linguaggi di <strong>scripting<\/strong> e linguaggi <strong>orientati agli oggetti<\/strong>.<br>Ognuno di questi paradigmi presenta caratteristiche peculiari, vantaggi, limitazioni e implicazioni per la sicurezza del codice prodotto.<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Linguaggi imperativi (procedurali)<\/strong><\/p>\n\n\n\n<p>La <strong>programmazione imperativa<\/strong> \u00e8 il paradigma classico in cui un programma \u00e8 visto come una sequenza di istruzioni che modificano lo stato del programma stesso (variabili, strutture dati) per ottenere il risultato desiderato. In altre parole, l\u2019attenzione \u00e8 sul <em>come <\/em>fare le cose: si specificano esplicitamente i passi da seguire, in ordine, includendo strutture di controllo come assegnamenti, cicli (<code> for <\/code>,<code> while <\/code>), condizionali (<code> if <\/code>\/<code> else <\/code>), chiamate di funzioni\/procedure, ecc. La maggior parte dei linguaggi tradizionali rientrano in questo paradigma: linguaggi <strong>procedurali <\/strong>come C, Pascal, BASIC, Fortran (dove esistono procedure e funzioni come unit\u00e0 di modularizzazione) sono imperativi; anche il linguaggio Assembly (di basso livello) \u00e8 imperativo puro, in quanto si scrivono istruzioni macchina che cambiano registri e memoria step-by-step. Persino linguaggi come Java o Python supportano uno stile imperativo (Python, ad esempio, pur essendo multi-paradigma, permette di scrivere codice procedurale imperativo). Caratteristiche tipiche di linguaggi imperativi\/procedurali includono la gestione esplicita della memoria (in C, ad esempio, con <code>malloc <\/code>\/<code> free <\/code>o lo stack frame delle funzioni), l\u2019uso di variabili mutate nel corso dell\u2019esecuzione e un flusso di controllo che pu\u00f2 usare costrutti come goto (nei casi pi\u00f9 base) o strutture strutturate. Il codice imperativo rispecchia l\u2019architettura di von Neumann: infatti questi linguaggi sono \u201cvicini al modo in cui lavora l\u2019elaboratore\u201d, aggiornando locazioni di memoria e eseguendo istruzioni in sequenza.<\/p>\n\n\n\n<p><strong>Implicazioni per la sicurezza<\/strong>: nei linguaggi imperativi a basso livello (es. C, C++, assembler) sta l\u2019origine di molte vulnerabilit\u00e0 classiche, proprio perch\u00e9 lasciano molto controllo (e responsabilit\u00e0) al programmatore. Ad esempio, la gestione manuale della memoria in C\/C++ \u00e8 fonte di bug quali buffer overflow, use-after-free, double free, integer overflow e cos\u00ec via, che se non prevenuti portano ad exploit di memoria e code execution arbitraria. Un responsabile della sicurezza deve conoscere bene questi rischi: ad esempio, l\u2019attacco <em>stack buffer overflow<\/em> sfrutta il fatto che in C si possono scrivere dati fuori dai limiti di un array, andando a sovrascrivere il return address di funzione nello stack; mitigazioni come canary, ASLR, NX bit sono stati sviluppati per attutire il problema, ma la vera soluzione \u00e8 scrivere codice robusto (o usare linguaggi che prevengono out-of-bounds, come Java o Rust). Nei contesti dove la performance e il controllo spingono a usare C\/C++ (kernel OS, driver, sistemi embedded, highperformance computing), \u00e8 cruciale adottare standard di codice sicuro (es. CERT C Coding Standard) e strumenti di analisi (sanitizer, static analysis) per ridurre i bug imperativi.<\/p>\n\n\n\n<p>Nei linguaggi imperativi di pi\u00f9 alto livello (es. Java, che \u00e8 orientato agli oggetti ma si pu\u00f2 vedere come imperativo nel flusso; o Python se scrivi script procedurali), molti errori di memoria sono evitati (garbage collector, check runtime su array, ecc.), ma persistono problemi come la gestione delle condizioni di errore, la concorrenza (race conditions se thread paralleli accedono a variabili condivise), etc. Il paradigma imperativo incoraggia l\u2019uso di stato mutabile e questo \u00e8 terreno di <em>race condition<\/em> e <em>TOCTOU (Time-of-check to time-of-use)<\/em> bugs: ad esempio, un programma imperativo multi-thread potrebbe controllare l&#8217;esistenza di un file e poi aprirlo; se tra check e open passa tempo e un attaccante cambia il file (symlink attack), abbiamo un TOCTOU bug. Un responsabile deve sapere che certe classi di vulnerabilit\u00e0 (soprattutto in codice multi-thread o multi-processo) derivano dalla difficolt\u00e0 di ragionare su stato mutabile e tempi di esecuzione \u2013 ecco perch\u00e9 paradigmi alternativi (es. la programmazione funzionale, che evita stato mutabile) vengono talvolta adottati per ridurre bug, ma la maggioranza del codice rimane imperativo.<\/p>\n\n\n\n<p>In campo offensivo, conoscere la natura imperativa dei programmi aiuta a fare reverse engineering: ad esempio, i malware scritti in C\/C++ compilano in assembly macchina e un analista dovr\u00e0 interpretare quell\u2019assembly come un flusso di operazioni (imperative) per capire cosa fa il malware. Saper leggere pseudocodice imperativo o flusso di un binario \u00e8 competenza essenziale in analisi malware\/forense.<\/p>\n\n\n\n<p><strong>Esempi di linguaggi imperativi popolari<\/strong>: C (usato per kernel, sistemi operativi, software di rete; critico per exploit), C++ (che aggiunge oggetti ma resta principalmente imperativo, usato in applicativi veloci, anche in diversi malware avanzati), Ada (in ambito aerospaziale, focus su sicurezza e affidabilit\u00e0), Go (Google Go, imperativo concurrent, con gestione memoria automatica e forte supporto al multithread \u2013 spesso usato per strumenti di rete e cloud, la sua semplicit\u00e0 riduce alcune classi di bug rispetto a C) e tanti altri incl. Rust (che pur supportando vari stili viene spesso usato in modo imperativo ma \u201cmemory safe\u201d grazie al suo sistema di propriet\u00e0).<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Linguaggi di scripting<\/strong><\/p>\n\n\n\n<p>Un <strong>linguaggio di scripting<\/strong> \u00e8 tipicamente un linguaggio interpretato, di alto livello, pensato per automatizzare compiti in un ambiente runtime esistente. Il termine deriva dal fatto che inizialmente questi linguaggi erano usati per scrivere <em>script <\/em>(copioni) che eseguono operazioni su sistemi operativi o applicazioni, invece che per sviluppare applicazioni stand-alone complesse. Caratteristiche comuni dei linguaggi di scripting includono: tipizzazione dinamica (non occorre dichiarare esplicitamente il tipo delle variabili), gestione automatica della memoria (garbage collection), sintassi semplice e concisa, e disponibilit\u00e0 di un ambiente interpretativo (shell, REPL) dove eseguire i comandi al volo.<br>Esempi classici sono <strong>bash\/sh<\/strong> (scripting di shell Unix), <strong>JavaScript <\/strong>originariamente scripting client-side per i browser, oggi grazie a Node.js usato anche lato server), <strong>Python, Perl, Ruby, PHP, PowerShell<\/strong> (scripting avanzato su Windows), ecc. Questi linguaggi spesso interagiscono con un sistema pi\u00f9 grande: ad esempio, JavaScript in una pagina web manipola l\u2019HTML\/CSS e il browser funge da runtime; Python pu\u00f2 essere usato come script per automazione di task di sistema, o incorporato in applicazioni; PHP \u00e8 un linguaggio di scripting lato server per generare contenuti web dinamici; Bash orchestr\u0430 comandi del sistema operativo e programmi.<\/p>\n\n\n\n<p>Il vantaggio dei linguaggi di scripting \u00e8 la <strong>produttivit\u00e0<\/strong> e la <strong>facilit\u00e0 d\u2019uso<\/strong>: permettono di sviluppare rapidamente funzionalit\u00e0 senza gestire i dettagli di basso livello (gestione memoria, compilazione). Questo li rende ideali per la scrittura di strumenti di automazione, estrazione di dati, prototipazione, e (nel nostro contesto) per molti script e tool di sicurezza. Un analista di sicurezza scrive comunemente script Python o Bash per analizzare log, per eseguire scansioni personalizzate, per automatizzare reazioni a incidenti (es. uno script che disattiva automaticamente un account sospetto su pi\u00f9 sistemi, integrandosi via API).<\/p>\n\n\n\n<p><strong>Implicazioni per la sicurezza<\/strong>: Da un lato, usando linguaggi di scripting si evitano molte vulnerabilit\u00e0 tipiche del C (buffer overflow, ecc.), quindi per script e tool interni spesso si preferisce Python o PowerShell per ridurre rischi di bug memory corruption. Dall\u2019altro lato, i linguaggi di scripting portano sfide proprie: essendo spesso interpretati, il <strong>codice pu\u00f2 essere pi\u00f9 facilmente letto\/modificato<\/strong> da un attaccante se trova gli script sul sistema (a meno di offuscazioni); e poich\u00e9 molti sono usati in contesti di elevati privilegi (si pensi a script Bash lanciati come root per manutenzioni, o script PowerShell per amministrazione di dominio), diventano bersagli: gli attaccanti possono tentare di alterare script esistenti (supply chain, se uno script viene scaricato da internet e poi eseguito con fiducia \u2013 come a volte succede con script di installazione), oppure usarli a proprio vantaggio (es. se un webserver permette di caricare ed eseguire file PHP, l\u2019attaccante pu\u00f2 caricare una <em>web shell<\/em> PHP, sfruttando il linguaggio di scripting del server per eseguire comandi arbitrari sul sistema). Ci\u00f2 sottolinea la necessit\u00e0 di trattare gli script come codice a tutti gli effetti: revisionare la sicurezza, proteggerli con controlli di integrit\u00e0, limitarne i permessi di esecuzione, ecc.<\/p>\n\n\n\n<p>Nei sistemi, spesso i linguaggi di scripting fungono da <strong>collante<\/strong>: ad esempio, un attaccante che abbia compromesso un server Linux potrebbe scrivere uno script bash per mantenere la persistenza (inserendolo magari in<code> \/etc\/init.d <\/code>per avviarsi al boot) o per esfiltrare dati periodicamente. Dunque, chi gestisce la sicurezza deve monitorare non solo eseguibili compilati ma anche i file di script, e utilizzare strumenti tipo <em>OSSEC <\/em>o <em>Tripwire <\/em>per notare modifiche anomale a script chiave.<br>Le applicazioni web scritte in linguaggi di scripting (PHP, Python via Django\/Flask, JavaScript via Node.js) ereditano i rischi di vulnerabilit\u00e0 applicative (XSS, injection, etc.), con la differenza che essendo i linguaggi spesso molto dinamici pu\u00f2 essere pi\u00f9 facile introdurre errori se non si seguono regole (es. in PHP, un tempo la registrazione globale delle variabili portava a vulnerabilit\u00e0 se non attenta; in Node.js, la presenza di un ricco ecosistema di package richiede attenzione alla supply chain e a aggiornare le dipendenze per evitare moduli malevoli).<\/p>\n\n\n\n<p><strong>Esempi pratici in scenario di sicurezza<\/strong>: uno script Python pu\u00f2 essere scritto per analizzare i pacchetti di rete (usando Scapy) e rilevare un pattern di scansione, inviando alert. Oppure script Bash vengono usati negli SIEM per parsare formati di log e normalizzarli. Con PowerShell, un team di incident response pu\u00f2 interrogare in modo massivo tutte le macchine di un dominio cercando indicatori di compromissione \u2013 infatti, oggi gli attaccanti stessi usano PowerShell per i loro scopi (PowerShell Empire e altri framework di post- exploitation): ci\u00f2 perch\u00e9 con script si integrano nativamente nell\u2019ambiente senza portare eseguibili che possano essere bloccati da whitelist. Un reaponsabile deve essere consapevole di queste tattiche e, ad esempio, abilitare <strong>PowerShell Logging<\/strong> e Constrained Language Mode su host Windows per avere visibilit\u00e0 e limitare l\u2019uso malevolo.<\/p>\n\n\n\n<p>In sintesi, i linguaggi di scripting sono potenti e flessibili; per la difesa informatica sono armi essenziali (per automazione e integrazione), ma vanno gestiti con regole di sicurezza come qualsiasi codice: controllo delle entrate (validazione input negli script), least privilege (non far girare script con privilegi oltre il necessario), mantenimento (aggiornare le versioni interpreter \u2013 molte falle in PHP\/Python stesso corrette con patch), e rilevamento di abuso (monitorare esecuzioni anomale, come un utente non amministrativo che improvvisamente lancia script PowerShell con comandi di dumping credenziali).<\/p>\n\n\n\n<p class=\"has-medium-font-size\"><strong>Linguaggi orientati agli oggetti (OOP)<\/strong><\/p>\n\n\n\n<p>La <strong>programmazione orientata agli oggetti (Object-Oriented Programming, OOP)<\/strong> \u00e8 un paradigma in cui il software viene modellato come un insieme di <strong>oggetti <\/strong>che interagiscono tra loro scambiandosi messaggi (chiamando metodi l\u2019uno dell\u2019altro). Un oggetto incapsula <strong>stato<\/strong> (dati, sotto forma di attributi\/variabili) e <strong>comportamento<\/strong> (funzionalit\u00e0, sotto forma di metodi\/funzioni). I linguaggi OOP offrono costrutti come <strong>classi<\/strong> (definizioni generiche da cui istanziare oggetti concreti), <strong>ereditariet\u00e0<\/strong> (una classe pu\u00f2 derivare da un\u2019altra ereditando attributi e metodi, consentendo specializzazione e riuso del codice), <strong>polimorfismo<\/strong> (il fatto che chiamate a metodi possano riferirsi a implementazioni diverse in classi diverse, tipicamente via overriding \u2013 es. diversi oggetti tipo <em>Figura<\/em> con metodo <em>disegna()<\/em> implementato diversamente in <em>Cerchio<\/em>, <em>Quadrato<\/em>), e <strong>incapsulamento <\/strong>(detto sopra: la capacit\u00e0 di nascondere i dettagli interni di un oggetto e offrire solo interfacce pubbliche \u2013 spesso con modificatori di accesso come <code>public\/private\/protected<\/code>).<\/p>\n\n\n\n<p>L\u2019OOP nasce per gestire meglio la complessit\u00e0 di grandi progetti software, modellando entit\u00e0 vicine al dominio reale e promuovendo modularit\u00e0 e riusabilit\u00e0. Ad esempio, in un sistema bancario si potrebbero avere classi Conto, Transazione, Cliente con relazioni di composizione e specializzazione (un ContoCorrente estende Conto aggiungendo un fido, etc.). Linguaggi strettamente OOP includono <strong>Java, C#, C++<\/strong> (ibrido, multi-paradigma ma con forte supporto OOP), <strong>Python<\/strong> (multi-paradigma ma con OOP completo), <strong>Ruby, JavaScript<\/strong> (che in realt\u00e0 \u00e8 basato su prototipi, ma concettualmente OOP), ecc. Oggi, OOP \u00e8 forse il paradigma dominante nello sviluppo di applicazioni enterprise.<\/p>\n\n\n\n<p><strong>Implicazioni per la sicurezza<\/strong>: la programmazione a oggetti porta benefici di organizzazione, ma introduce anche superfici di attacco peculiari. Ad esempio, la presenza di gerarchie di classi e funzioni virtuali apre il fianco a attacchi come l\u2019<strong>overwrite di puntatori virtuali<\/strong> in exploit memory corruption (in C++ un oggetto ha un vtable pointer \u2013 se un buffer overflow sovrascrive quel puntatore, un attaccante pu\u00f2 far eseguire codice arbitrario quando il programma chiamer\u00e0 un metodo virtuale dell\u2019oggetto). Questa \u00e8 una considerazione bassa, valida solo in linguaggi non memory-safe (C++): mitigazioni come <em>Control Flow Guard<\/em> di Microsoft cercano proprio di impedire salto a vtable rogue.<\/p>\n\n\n\n<p>Dal punto di vista di design, l\u2019OOP a volte incoraggia un\u2019eccessiva fiducia sugli oggetti \u2013 ad esempio, concetti come l\u2019<strong>esecuzione di codice mobile<\/strong>: Java Applet, ActiveX, .NET assemblies, tutti casi in cui oggetti provenienti da terze parti vengono eseguiti localmente, con meccanismi di sandbox vari (Java aveva il security manager per applet, ActiveX si basava su firme digitali \u2013 con noti problemi se l\u2019utente autorizzava un controllo malevolo). Questo scenario di <em>mobile code<\/em> necessita che i runtime siano robusti nel far rispettare i confini (spesso non lo furono, portando a deprecazione di tali tecnologie).<\/p>\n\n\n\n<p>Un altro punto: i <strong>framework ad oggetti<\/strong> (tipici in Java, C#) che fanno ampio uso di riflessione e serializzazione. La <strong>serializzazione di oggetti<\/strong> \u00e8 la capacit\u00e0 di convertire un oggetto in una forma (tipicamente binaria o testuale) per salvarlo o trasmetterlo, e poi ricostruirlo. Questo meccanismo ha portato a exploit come le <strong>deserialization vulnerabilities<\/strong>: se un\u2019app accetta da input un oggetto serializzato (ad esempio, un token di sessione Java serializzato inviato nel cookie) un attaccante potrebbe manipolarlo per far istanziare oggetti malevoli o con stati inconsistenze. Ci sono state grosse vulnerabilit\u00e0 (es. CVE di Apache Commons-Collections e altri, dove un oggetto opportunamente costruito portava all\u2019esecuzione di comandi arbitrari durante la deserializzazione, perch\u00e9 la classe aveva blocchi statici o metodi finalize con chiamate pericolose). Un responsabile deve conoscere questi pattern: ad esempio, in pen test su applicazioni Java enterprise, la deserializzazione non sicura \u00e8 un must-check. La <em>best practice<\/em> \u00e8 evitare la deserializzazione di oggetti da fonti non fidate, o usare formati sicuri (JSON, protocolli con schema), o whitelisting di classi deserializzabili.<\/p>\n\n\n\n<p><strong>Controllo degli accessi a oggetti<\/strong>: OOP a volte induce a pensare che i controlli possano essere fatti a livello di oggetto, ma in ambienti multi-utente\/multi-tenant non basta. Ad esempio, in un\u2019app web OOP potrebbe esserci metodo <code>Documento.approva()<\/code>; ma bisogna assicurarsi a livello applicativo che l\u2019utente X possa approvare solo i documenti di sua competenza. Ci\u00f2 porta a vulnerabilit\u00e0 come <strong>Insecure Direct Object Reference (IDOR)<\/strong>: se l\u2019app espone un endpoint <code>\/documento\/approva?id=123<\/code> che chiama internamente <code>doc.approva()<\/code>, un utente malintenzionato potrebbe fornire un id di un documento che non dovrebbe poter modificare e se manca il controllo, l\u2019oggetto viene comunque recuperato e il metodo invocato (violazione autorizzazione). L\u2019approccio OOP puro a volte fa sottovalutare questo \u2013 perch\u00e9 a livello di codice, chiamare il metodo \u00e8 lecito, ma manca il contesto di sicurezza. Quindi, un principio: integrare <strong>controlli di autorizzazione<\/strong> in tutti i metodi sensibili, oppure usare un framework di sicurezza (es. Spring Security) che si integri con l\u2019OOP (annotation tipo <code>@PreAuthorize<\/code> su metodi, ecc.).<\/p>\n\n\n\n<p><strong>Benefici OOP per la sicurezza<\/strong>: d\u2019altro canto, se ben applicato, OOP migliora la sicurezza del codice: l\u2019incapsulamento pu\u00f2 prevenire accessi indesiderati \u2013 se tutti gli campi sono <code>private <\/code>e l\u2019oggetto valida i dati tramite setter, \u00e8 pi\u00f9 difficile corrompere lo stato. L\u2019ereditariet\u00e0 e polimorfismo possono favorire la scrittura di <strong>checker di sicurezza generici<\/strong>: ad esempio, una classe base <code>Utente <\/code>con metodo virtuale <code>haPermesso(azione)<\/code> pu\u00f2 essere implementata diversamente in <code>UtenteStandard<\/code> e <code>Admin<\/code>, permettendo all\u2019app di chiedere genericamente <code>utente.haPermesso(\"DELETE_USER\")<\/code> senza conoscere la classe concreta \u2013 design pulito che centralizza logica di auth. Tuttavia, se un attaccante riesce a far istanziare una sottoclasse controllata (vedi problema deserialization su classpath), quell\u2019interfaccia generica potrebbe rispondere \u201cs\u00ec ho permesso\u201d falsamente. Perci\u00f2 la riflessione insegna: l\u2019OOP va usato con coscienza e meccanismi magici come riflessione, dependency injection, ecc. vanno vigilati. Ad esempio, i container di inversion of control (Spring, etc.) automaticamente <em>viranano<\/em> dipendenze tra oggetti; se configurati male, potrebbero esporre bean sensibili su canali remoti (vedi ad es. JMX misconfigurato, o endpoint actuator in Spring Boot esposti senza auth, che permettono di manipolare runtime).<\/p>\n\n\n\n<p>In <strong>termini di linguaggi concreti<\/strong>: <strong>Java<\/strong> e <strong>C#<\/strong> sono fortemente tipizzati e gestiti, riducono molti errori (no buffer overflow classici), ma ricordiamo incidenti come <em>Log4Shell <\/em>(una vulnerabilit\u00e0 in un logger che attraverso un lookup JNDI permetteva di scaricare un oggetto remoto \u2013 combinazione di serializzazione, rete e riflessione). Dunque, anche se il linguaggio previene certi bug, rimane la superficie dei <em>runtime environment<\/em> (JVM, .NET) e delle librerie di base. <strong>C++<\/strong> aggiunge OOP al C ma mantiene la pericolosit\u00e0 del controllo manuale: cos\u00ec somma rischi (memory + OOP). Sviluppatori esperti possono scrivere codice sicuro, e moderne guidelines (C++ Core Guidelines) spingono a usare costrutti sicuri (smart pointer invece di raw pointer, etc.), ma molto codice legacy \u00e8 vulnerabile. <strong>Python, JavaScript, PHP, Ruby<\/strong> supportano OOP ma in modo dinamico: qui la flessibilit\u00e0 \u00e8 massima (es. in Python puoi aggiungere attributi a runtime agli oggetti, in JavaScript modificare prototipi al volo), e questo dinamismo pu\u00f2 essere sfruttato malevolmente. Ad esempio, <em>Prototype Pollution<\/em> in JavaScript: se una libreria non isola bene i dati, un attaccante pu\u00f2 iniettare propriet\u00e0 nell\u2019Object prototype globale, influenzando tutti gli oggetti (impatto a cascata su app intera). Ci\u00f2 evidenzia che la <em>surface <\/em>di errori si sposta: meno memory corruption, pi\u00f9 logiche e inconsistenze.<\/p>\n\n\n\n<p><strong>Paradigmi misti<\/strong>: molti team oggi adottano linguaggi multi-paradigma (es. Python, JavaScript) o abbracciano stili come la <em>programmazione funzionale <\/em>all\u2019interno di contesti OOP (es. metodi immutabili, uso di lambda e stream in Java). La programmazione funzionale riduce certi bug (immutatibilit\u00e0 -&gt; no race, no side effects difficili), ma non sempre \u00e8 praticabile da sola (sistemi I\/O, UI etc. spesso sono pi\u00f9 facilmente espressi con oggetti). Tuttavia, un responsabile dovrebbe promuovere \u201cil giusto strumento per il lavoro\u201d: in componenti dove la robustezza \u00e8 critica, valutare linguaggi memory-safe (Java, C#) o addirittura \u201cprovably safe\u201d (es. Rust in sistemi), oppure script come Python per prototipi e analisi rapida sapendo che saranno un po\u2019 pi\u00f9 lenti. Per parti performance-critical ma delicate, considerare tecniche di verifica (es. strumenti di static analysis, o addirittura approcci formali se giustificato, come SPARK\/Ada per software militare).<\/p>\n\n\n\n<p><strong>Sicurezza e ciclo di vita del software<\/strong>: indipendentemente dal linguaggio o paradigma, contano i processi: code review, static analysis, fuzzing, patching, gestione dipendenze (questo soprattutto in scripting: pip\/npm composer \u2013 supply chain risk). Un responsabile dovrebbe assicurarsi che i team di sviluppo seguano secure coding guidelines e che ogni linguaggio usato abbia i suoi checker (es. linters, SonarQube ruleset per Java, ESLint\/Retire.js per JS, Bandit per Python, PHPStan per PHP, ecc.).<\/p>\n\n\n\n<p>In conclusione, comprendere i vari tipi di linguaggi e paradigmi consente a un responsabile della sicurezza di <strong>dialogare efficacemente con gli sviluppatori<\/strong> e valutare i rischi del software in esame. Ad esempio, se un nuovo sistema da proteggere \u00e8 scritto in C++ con moduli Python embedded (come a volte succede in tool scientifici), egli sapr\u00e0 che deve considerare sia vulnerabilit\u00e0 a basso livello (C++) sia di alto livello (injection possibili in Python eval? ecc.). Se invece la sua organizzazione passa a microservizi in Node.js e Go, studier\u00e0 gli specifici pitfalls (Prototype pollution, moduli npm malevoli, vs concurrency issues e memory usage in Go). In definitiva, la diversit\u00e0 di linguaggi riflette la diversit\u00e0 di problemi da risolvere; per la sicurezza informatica, ogni linguaggio\/paradigma aggiunge un tassello: conoscendoli, si pu\u00f2 implementare difese profonde (ad esempio: firewall WAF che riconosce attacchi comuni in PHP vs in Node), e soprattutto prevenire incidenti formando i team di sviluppo sulle giuste pratiche per quel contesto (ad es., per Java: \u201cattenti alla deserializzazione di oggetti\u201d; per C: \u201cusa snprintf invece di sprintf per prevenire overflow\u201d; per JavaScript: \u201cvalida bene input prima di usarli in DOM  manipulations per evitare XSS\u201d, e cos\u00ec via). Un professionista completo di sicurezza sa quindi muoversi trasversalmente tra il codice, individuando pattern pericolosi e suggerendo soluzioni appropriate al paradigma in uso.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduzione Il presente articolo vuole fornire una panoramica strutturata dei fondamenti di informatica e reti di calcolatori, con un focus sull\u2019applicazione pratica di tali conoscenze nel contesto della sicurezza informatica. Ciascuna sezione approfondisce un argomento chiave \u2013 dalla rappresentazione dei dati ai sistemi operativi, dalle basi di dati alle reti e protocolli \u2013 evidenziando i &hellip; <a href=\"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/08\/21\/fond-inform-reti-calc-sic-inform\/\" class=\"more-link\">Leggi tutto<span class=\"screen-reader-text\"> &#8220;Fondamenti di informatica e reti di calcolatori per la sicurezza informatica&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[12,14,17],"tags":[21,23,26,27,24,20,25,22],"class_list":["post-2202","post","type-post","status-publish","format-standard","hentry","category-cyber-security","category-digital-forensics","category-networking","tag-architettura-degli-elaboratori","tag-basi-di-dati-relazionali-e-nosql","tag-fondamenti-di-algoritmi","tag-linguaggi-di-programmazione","tag-networking-e-principali-protocolli-di-rete","tag-rappresentazione-delle-informazioni","tag-reti-di-elaboratori","tag-sistemi-operativi"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2202","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=2202"}],"version-history":[{"count":138,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2202\/revisions"}],"predecessor-version":[{"id":3383,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2202\/revisions\/3383"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2202"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}