Consulente ICT ICT Consultant

Il Problema: I Ransomware che cifrano il Disaster Recovery

Immagine realizzata con Gemini AI

Il più grande incubo di un sistemista non è un ransomware che blocca i dati di produzione, ma un ransomware "smart" che, prima di rivelarsi, cerca nel network le share SMB, i NAS e i repository di backup cifrandoli. Se il malware ha accesso in scrittura alla destinazione dei tuoi backup, l'intero piano di Disaster Recovery è annullato.

La Soluzione: Architettura di Backup Immutabile su Linux

Per sconfiggere questa minaccia serve l'immutabilità: un file salvato non deve poter essere modificato, sovrascritto o cancellato, nemmeno dall'utente root. Utilizzando gli attributi nativi dei file system Linux (ext4/xfs), possiamo creare un repository "antiproiettile" a costo zero.

Il comando magico: chattr

Una volta che la tua procedura di backup (es. rsync o un cron job) ha trasferito l'archivio sul server di deposito Linux, aggiungi una riga per bloccare il file a livello di kernel utilizzando il flag +i (immutable):

# Il file di backup viene reso inalterabile
sudo chattr +i /backup/repository/server_db_lunedì.tar.gz

Se un hacker ottiene l'accesso al server ed esegue uno script crittografico, il kernel respingerà l'operazione. Per permettere la rotazione dei vecchi backup, uno script blindato rimuoverà temporaneamente il flag (-i), cancellerà il file obsoleto e rimetterà il lucchetto sui nuovi arrivi.

The Problem: Ransomware Encrypting Disaster Recovery Plans

Image generated with Gemini AI

A sysadmin's biggest nightmare is not ransomware locking production data, but "smart" ransomware that, before revealing itself, searches the network for SMB shares, NAS devices, and backup repositories to encrypt them. If the malware has write access to your backup destination, your entire Disaster Recovery plan is nullified.

The Solution: Immutable Backup Architecture on Linux

To defeat this threat, you need immutability: a saved file must not be modifiable, overwritable, or deletable, not even by the root user. By using native Linux file system attributes (ext4/xfs), we can create a "bulletproof" repository at zero cost.

The Magic Command: chattr

Once your backup procedure (e.g., rsync or a cron job) has transferred the archive to the Linux storage server, append a line to lock the file at the kernel level using the +i (immutable) flag:

# The backup file is made unalterable
sudo chattr +i /backup/repository/server_db_monday.tar.gz

If a hacker gains access to the server and runs a cryptographic script, the kernel will reject the operation. To allow the rotation of old backups, a highly hardened script must temporarily remove the flag (-i), delete the obsolete file, and reapply the lock to the new arrivals.

Il Problema: L'escalation di privilegi tramite Kerberoasting

Immagine generata con Gemini AI

Active Directory (AD) è il cuore pulsante delle infrastrutture aziendali, ma le sue configurazioni legacy lo rendono un bersaglio primario. Uno degli attacchi più letali e silenziosi è il Kerberoasting. Gli attaccanti, pur avendo accesso con un account utente standard senza privilegi, possono richiedere i ticket di servizio (TGS) per qualsiasi account associato a un Service Principal Name (SPN). Poiché questi ticket sono cifrati con l'hash della password dell'account di servizio, gli hacker li esportano offline per tentare attacchi di brute-force ed estrarre la password in chiaro.

La Soluzione: Hardening degli SPN e policy crittografiche

La mitigazione di questa vulnerabilità richiede un approccio a due livelli, agendo sia sulla complessità delle credenziali che sugli algoritmi di cifratura utilizzati dal dominio.

1. Password complesse per i Service Account

La difesa più efficace contro il cracking offline è la lunghezza. Gli account di servizio con SPN registrati (come quelli usati per SQL Server o IIS) devono avere password generate casualmente di almeno 30 caratteri. Implementa le Managed Service Accounts (gMSA) dove possibile, affinché Windows gestisca e ruoti automaticamente queste password complesse in totale trasparenza.

2. Disabilitare la cifratura RC4

I ticket cifrati con il vecchio protocollo RC4 sono triviali da forzare. Forza l'utilizzo di AES-256 modificando la Group Policy Object (GPO) del dominio:

# Imposta i tipi di crittografia supportati per Kerberos tramite GPO
# Percorso: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# Network security: Configure encryption types allowed for Kerberos
# Selezionare solo: AES128_HMAC_SHA1 e AES256_HMAC_SHA1

Una volta applicata la GPO, gli attaccanti che tenteranno di esportare i ticket si scontreranno con un algoritmo matematicamente impraticabile da forzare in tempi utili.

The Problem: The Security Illusion of Traditional VPNs

Image generated with Gemini AI

For decades, the corporate perimeter was defended using the "castle and moat" model: a robust external firewall and a VPN for remote workers. However, if an attacker compromises the credentials of a VPN-connected employee, they gain indiscriminate access to the entire LAN (Lateral Movement), easily infecting file servers and domain controllers.

The Solution: Zero Trust Network Access (ZTNA)

The modern approach mandates the Zero Trust paradigm: "Never trust, always verify." Access is no longer granted based on network location, but on the identity and posture of the device for every single session.

1. Micro-segmentation and Identity Providers (IdP)

Instead of exposing the entire network, ZTNA establishes end-to-end encrypted tunnels to individual applications (e.g., only to the ERP or internal web server). By using Azure AD or Okta as an IdP, mandatory Multi-Factor Authentication (MFA) and conditional policies are enforced: if an employee's PC lacks an updated antivirus, access is denied even if the password is correct.

2. Abandoning the "Trusted Network" Concept

By implementing solutions like Cloudflare Access or Tailscale, internal applications don't even require open ports on the corporate firewall, becoming "invisible" on the Internet but securely accessible to authorized users.

The Problem: The "Flat" Network and Lateral Movement

Image generated with Gemini AI

In many legacy corporate infrastructures, all devices (office computers, production servers, IP cameras, and guest Wi-Fi) reside on the exact same subnet (e.g., 192.168.1.0/24). If an employee opens a malicious attachment and triggers a ransomware payload, the malware exploits this "flat" architecture to perform lateral movement, instantly scanning and infecting critical servers and backup repositories without encountering a single network obstacle.

The Solution: Segmentation via VLANs and Firewalls

The principle of least privilege applies to networking as well. We must physically or logically isolate different corporate areas using VLANs (Virtual Local Area Networks) and route traffic through an internal firewall to inspect and block unauthorized communications.

1. Creating VLANs (Logical Isolation)

On your managed switches (Layer 2 or Layer 3), carve out distinct network segments. A standard minimal architecture includes:

• VLAN 10 (Management): 10.0.10.0/24 - Exclusive sysadmin access to hypervisors, switches, and iLOs.
• VLAN 20 (Servers): 10.0.20.0/24 - Application servers, databases, and Active Directory.
• VLAN 30 (Clients): 10.0.30.0/24 - Employee workstations.
• VLAN 40 (IoT/Printers): 10.0.40.0/24 - Vulnerable embedded devices.

2. Inter-VLAN Routing and Firewall Rules

Without a router or firewall (like pfSense or FortiGate) acting as the gateway, VLANs cannot communicate. Enforce strict firewall rules to allow only strictly necessary traffic. For example, clients (VLAN 30) must not be able to initiate RDP sessions to servers (VLAN 20); only the Management VLAN should have that capability.

# Logical Firewall Rule Example on pfSense
Action: PASS
Interface: VLAN_CLIENT
Source: VLAN_CLIENT Subnet
Destination: VLAN_SERVER Subnet
Ports: 443 (HTTPS), 3306 (MySQL)

Action: DROP
Interface: VLAN_CLIENT
Source: ANY
Destination: VLAN_SERVER Subnet
Ports: 3389 (RDP), 22 (SSH)

Conclusion

Network segmentation transforms your infrastructure from an open prairie into a series of watertight compartments. If an endpoint is compromised, the blast radius is confined strictly within its VLAN, saving critical services and backups from total destruction.

Il Problema: La Rete "Piatta" e il Movimento Laterale

Immagine realizzata con Gemini AI

In molte infrastrutture aziendali legacy, tutti i dispositivi (computer degli uffici, server di produzione, telecamere IP e Wi-Fi ospiti) risiedono sulla stessa subnet (es. 192.168.1.0/24). Se un dipendente apre un allegato malevolo e innesca un ransomware, il malware sfrutta questa architettura "piatta" per eseguire un movimento laterale, scansionando e infettando istantaneamente i server critici e i repository di backup senza alcun ostacolo di rete.

La Soluzione: Segmentazione tramite VLAN e Firewall

Il principio del privilegio minimo si applica anche al networking. Dobbiamo isolare fisicamente o logicamente le diverse aree aziendali utilizzando le VLAN (Virtual Local Area Network) e instradare il traffico attraverso un firewall interno per bloccare le comunicazioni non autorizzate.

1. Creazione delle VLAN (Isolamento Logico)

Sui tuoi switch gestiti (Layer 2 o Layer 3), crea segmenti di rete distinti. Un'architettura standard minima prevede:

• VLAN 10 (Management): 10.0.10.0/24 - Accesso esclusivo per i Sysadmin a hypervisor, switch e iLO.
• VLAN 20 (Server): 10.0.20.0/24 - Server applicativi, database e Active Directory.
• VLAN 30 (Client): 10.0.30.0/24 - Workstation dei dipendenti.
• VLAN 40 (IoT/Stampanti): 10.0.40.0/24 - Dispositivi embedded vulnerabili.

2. Regole di Routing e Firewall Inter-VLAN

Senza un router o un firewall (come pfSense o FortiGate) a fare da gateway, le VLAN non possono comunicare tra loro. Applica regole rigide sul firewall per consentire solo il traffico strettamente necessario. Ad esempio, i client (VLAN 30) non devono poter avviare sessioni RDP verso i server (VLAN 20); solo la VLAN di Management può farlo.

# Esempio logico di regola Firewall su pfSense (UFW non gestisce VLAN routing)
Azione: PASS
Interfaccia: VLAN_CLIENT
Sorgente: VLAN_CLIENT Subnet
Destinazione: VLAN_SERVER Subnet
Porte: 443 (HTTPS), 3306 (MySQL)

Azione: DROP
Interfaccia: VLAN_CLIENT
Sorgente: ANY
Destinazione: VLAN_SERVER Subnet
Porte: 3389 (RDP), 22 (SSH)

Conclusione

Segmentare la rete trasforma l'infrastruttura da una prateria aperta a una serie di compartimenti stagni. Se un endpoint viene compromesso, il raggio dell'attacco (blast radius) rimane confinato all'interno della sua VLAN, salvando i servizi critici e i backup.

The Problem: Invisible Data Exfiltration via LLMs

Image generated with Gemini AI

The Shadow IT phenomenon has evolved. Today, the primary threat is no longer the unauthorized cloud server, but Shadow AI. To speed up their workflow, employees are pasting source code, confidential contracts, or financial data (PII) into public AI chatbots (like the free versions of ChatGPT or Claude). Because these tools often use user prompts to train their language models, the company's sensitive data is irrevocably exposed outside the corporate security perimeter.

The Solution: Policies, DNS Filtering, and Enterprise AI

Simply blocking access to AI tools generates frustration and pushes users to find loopholes (e.g., hotspot connections). The solution requires a three-tiered approach.

1. Visibility and Network-Level Blocking

The first step is to stop the data hemorrhage to unauthorized endpoints. Configure the corporate firewall or DNS resolver (like Pi-hole or NextDNS) to monitor and block queries to the public APIs of major uncontracted AI providers.

# Example domains to add to the DNS blocklist
api.openai.com
chatgpt.com
claude.ai
gemini.google.com

2. Implementing Enterprise AI (Walled Garden)

To maintain productivity without compromising security, you must provide a safe alternative. Deploy private instances via enterprise cloud services (such as Google Cloud Vertex AI or Azure OpenAI) where contracts explicitly guarantee that data will not be used for model training. Alternatively, for highly classified data, deploy open-source LLMs (like Llama 3) locally on on-premise servers.

3. Endpoint DLP Configuration

Update Data Loss Prevention (DLP) software policies on endpoints to detect and block attempts to copy-paste sensitive strings (e.g., credit card numbers, IBANs, or proprietary code) into browser windows directed at URL categories classified as "Generative AI".

Il Problema: L'esfiltrazione invisibile dei dati tramite LLM

Immagine realizzata con Gemini AI

Il fenomeno dello Shadow IT si è evoluto. Oggi la minaccia principale non è più il server cloud non autorizzato, ma la Shadow AI. I dipendenti, per velocizzare il lavoro, incollano codice sorgente, contratti riservati o dati finanziari (PII) all'interno di chatbot IA pubblici (come la versione gratuita di ChatGPT o Claude). Poiché questi strumenti utilizzano spesso i prompt degli utenti per addestrare i propri modelli linguistici, i dati sensibili dell'azienda vengono irrimediabilmente esposti all'esterno del perimetro di sicurezza aziendale.

La Soluzione: Policy, DNS Filtering ed Enterprise AI

Bloccare semplicemente l'accesso agli strumenti IA genera frustrazione e spinge gli utenti a trovare scappatoie (es. connessioni hotspot). La soluzione richiede un approccio a tre livelli.

1. Visibilità e Blocco a livello di Rete

Il primo passo è fermare l'emorragia di dati verso endpoint non autorizzati. Configura il firewall aziendale o il resolver DNS (come Pi-hole o NextDNS) per monitorare e bloccare le query verso le API pubbliche dei principali fornitori IA non contrattualizzati.

# Esempio di domini da inserire in blocklist DNS
api.openai.com
chatgpt.com
claude.ai
gemini.google.com

2. Implementazione di IA Aziendale (Walled Garden)

Per mantenere la produttività senza compromettere la sicurezza, è necessario fornire un'alternativa sicura. Implementa istanze private tramite servizi cloud enterprise (come Google Cloud Vertex AI o Azure OpenAI) dove i contratti garantiscono esplicitamente che i dati non verranno utilizzati per il training dei modelli. In alternativa, per dati ad altissima classificazione, distribuisci LLM open-source (come Llama 3) localmente sui server aziendali.

3. Configurazione Endpoint DLP

Aggiorna le policy del software di Data Loss Prevention (DLP) sugli endpoint per rilevare e bloccare i tentativi di copia-incolla di stringhe sensibili (es. numeri di carte di credito, IBAN o codice proprietario) all'interno delle finestre del browser dirette a categorie URL classificate come "Generative AI".

Image generated with Gemini AI

The Problem: Cleartext Passwords in Source Code

Automation via scripting is the beating heart of system administration. However, hardcoding credentials (passwords, API tokens, cryptographic keys) in cleartext inside .sh or .ps1 files is a critical security violation. Anyone with read access to the file system or the Git repository compromises the entire corporate ecosystem.

The Solution: Encrypted Secrets Management

We must decouple the script's logic from the sensitive data by leveraging the operating system's native protection mechanisms.

1. In PowerShell Environments (Windows)

In Microsoft infrastructures, we can use Export-Clixml to encrypt a credential object. The encryption is tightly bound to the user account that generated it and the physical machine (thanks to the Windows Data Protection API).

# Run once to save the encrypted password
Get-Credential | Export-Clixml -Path "C:\secure\admin_creds.xml"

# In the production script, call the file:
$cred = Import-Clixml -Path "C:\secure\admin_creds.xml"

2. In Bash Environments (Linux)

On Unix systems, the most immediate, zero-cost method to protect daemons and cron scripts is to isolate variables into a separate configuration file, restricting permissions exclusively to the root user.

# Create the protected configuration file
echo "DB_PASS='SuperSecret!'" > /etc/script_secrets.conf
sudo chmod 400 /etc/script_secrets.conf

In the main script (executed with elevated privileges), simply import the variables using the source /etc/script_secrets.conf command. The code remains clean, and credentials remain invisible to unauthorized users.

Il Problema: Password in Chiaro nei Sorgenti

L'automazione tramite scripting è il cuore nevralgico della gestione sistemistica. Tuttavia, hardcodare credenziali (password, token API, chiavi crittografiche) in chiaro all'interno di file .sh o .ps1 è una violazione critica della sicurezza. Chiunque abbia accesso in lettura al file system o al repository Git compromette l'intero ecosistema aziendale.

Immagine realizzata con Gemini AI

La Soluzione: Gestione Cifrata dei Segreti

Dobbiamo disaccoppiare la logica dello script dal dato sensibile, sfruttando i meccanismi di protezione nativi del sistema operativo.

1. In Ambiente PowerShell (Windows)

In infrastrutture Microsoft, possiamo usare Export-Clixml per cifrare un oggetto credenziale. La cifratura è legata a doppio filo all'account utente che l'ha generata e alla macchina fisica (grazie alle API di Data Protection di Windows).

# Eseguire una volta per salvare la password cifrata
Get-Credential | Export-Clixml -Path "C:\secure\admin_creds.xml"

# Nello script di produzione, richiamare il file:
$cred = Import-Clixml -Path "C:\secure\admin_creds.xml"

2. In Ambiente Bash (Linux)

Nei sistemi Unix, il metodo più immediato e a costo zero per proteggere i demoni e gli script cron è isolare le variabili in un file di configurazione separato, restringendo i permessi esclusivamente all'utente root.

# Creare il file di configurazione protetto
echo "DB_PASS='SuperSegreta!'" > /etc/script_secrets.conf
sudo chmod 400 /etc/script_secrets.conf

Nello script principale (eseguito con privilegi elevati), basta importare le variabili con il comando source /etc/script_secrets.conf. Il codice rimane pulito e le credenziali risultano invisibili agli utenti non autorizzati.

Image Generated with Gemini AI

The Problem: Default Exposure

A freshly installed Linux server exposed to the public cloud is a blank canvas, but also an easy target. Default SSH daemon configurations and open ports immediately attract automated scanners, botnets, and brute-force attacks.

The Solution: 5 Steps to Hardening

Before installing any enterprise application, the infrastructure must be locked down by enforcing the principle of least privilege.

• 1. Public Key Authentication: Ditch passwords entirely. Generate a certificate using ssh-keygen, copy it to the server, and edit /etc/ssh/sshd_config by setting PasswordAuthentication no.
• 2. Disable Root Login: In the same SSH configuration file, ensure you set PermitRootLogin no to force access only via standard users and subsequent privilege elevation via sudo.
• 3. Firewall Segmentation (UFW): Drop all incoming traffic except what is strictly necessary.

  sudo ufw default deny incoming
  sudo ufw allow ssh
  sudo ufw enable

• 4. Brute-Force Mitigation (Fail2Ban): Automatically ban malicious IPs at the network level that repeatedly fail login attempts.

  sudo apt install fail2ban -y

• 5. Silent Updates: Keep the system protected from zero-day vulnerabilities by installing unattended-upgrades for the automatic application of critical security patches without service interruptions.

Immagine generata con Gemini AI

Il Problema: L'Esposizione Predefinita

Un server Linux appena installato ed esposto su cloud pubblico è una tela bianca, ma anche un bersaglio facile. Le configurazioni predefinite del demone SSH e le porte aperte attirano immediatamente scansioni automatizzate, botnet e attacchi brute-force.

La Soluzione: 5 Passaggi di Hardening

Prima di installare qualsiasi applicativo aziendale, l'infrastruttura deve essere blindata applicando il principio del minimo privilegio.

• 1. Autenticazione a Chiave Pubblica: Abbandona le password. Genera un certificato con ssh-keygen, copialo sul server e modifica /etc/ssh/sshd_config impostando PasswordAuthentication no.
• 2. Disabilitare l'accesso Root: Nello stesso file di configurazione SSH, assicurati di inserire PermitRootLogin no per forzare l'accesso solo tramite utenza standard e successiva elevazione tramite sudo.
• 3. Segmentazione con Firewall (UFW): Chiudi tutto il traffico in ingresso tranne lo stretto necessario.

  sudo ufw default deny incoming
  sudo ufw allow ssh
  sudo ufw enable

• 4. Mitigazione Brute-Force (Fail2Ban): Banna automaticamente a livello di rete gli IP malevoli che falliscono ripetutamente i login.

  sudo apt install fail2ban -y

• 5. Aggiornamenti Silenti: Mantieni il sistema protetto dalle vulnerabilità zero-day installando unattended-upgrades per l'applicazione automatica delle sole patch di sicurezza critiche, senza interruzioni di servizio.

A quick update for IT Chronicle readers. If you've noticed a slight slowdown in publications recently, there's a great reason: I'm heavily engaged out in the field.

Preparing a Real IT Audit

I am putting together a very special and highly practical series of articles. I will take you behind the scenes of conducting an IT Audit in a real-world environment.

Currently, I am in the delicate "groundwork" phase: conducting stakeholder interviews and mapping business processes. But don't worry, we will soon move to the operational phase. We'll get our hands dirty on the command line and see enterprise-grade tools in action for asset discovery, starting with exceptional software like runZero.

Coming Soon: New IT First Aid Episodes

To make sure I don't leave you empty-handed during this preparation phase, over the next few days I will be publishing a batch of new IT First Aid episodes that I prepared recently. We will continue to tackle the most annoying Windows issues, fixing them with a sysadmin approach.

Continuous Learning: Cloud & Generative AI

In the ICT world, standing still means falling behind. To best support modern infrastructures and focus on IT governance, I have officially embarked on two challenging new Google certification paths: Professional Cloud Architect and Generative AI Leader.

I will also share the most interesting insights that emerge from these studies. Stay tuned, there is a lot on the way!

Un breve aggiornamento per i lettori di IT Chronicle. Se nelle ultime settimane avete notato un leggero rallentamento nelle pubblicazioni, c'è un ottimo motivo: sono intensamente impegnato sul campo.

Preparazione di un vero IT Audit

Sto preparando una nuova serie di articoli molto speciali e, soprattutto, estremamente pratici. Vi porterò dietro le quinte della realizzazione di un IT Audit in un ambiente reale.

Attualmente mi trovo nella delicata fase di "preparazione del terreno": sto conducendo le interviste con gli stakeholder e mappando i processi aziendali (il vero cuore del Risk Management). Ma non temete, molto presto passeremo alla fase operativa. Ci sporcheremo le mani sulla riga di comando e vedremo in azione strumenti di livello enterprise per l'asset discovery e l'analisi dell'infrastruttura, a partire da tool eccezionali come runZero.

In arrivo: nuovi episodi del Pronto Soccorso IT

Per non lasciarvi a mani vuote durante questa fase di studio e preparazione strategica, nei prossimi giorni pubblicherò una serie di nuovi episodi del Pronto Soccorso IT che ho preparato e programmato nei giorni scorsi. Continueremo ad affrontare le problematiche Windows più fastidiose, risolvendole con l'approccio chirurgico di un sistemista.

Aggiornamento continuo: Cloud & Generative AI

Nel mondo ICT fermarsi significa retrocedere. Per supportare al meglio le infrastrutture moderne e puntare sempre di più alla governance IT, ho ufficialmente intrapreso due nuovi e sfidanti percorsi di certificazione di Google: Professional Cloud Architect e Generative AI Leader.

Condividerò con voi anche gli spunti più interessanti che emergeranno da questi studi. Restate sintonizzati, abbiamo molta carne al fuoco!