Consulente ICT ICT Consultant

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.

Il Problema: Connettività Presente, Risoluzione Assente

Immagine realizzata con Gemini AI

È un incubo ricorrente: il server risponde al ping 8.8.8.8, ma provando a raggiungere un dominio interno o esterno il browser restituisce ERR_NAME_NOT_RESOLVED. Il comando ipconfig /flushdns non ha sortito alcun effetto. In questi scenari avanzati, limitarsi a riavviare la scheda di rete è inutile; serve ispezionare chirurgicamente la catena di risoluzione.

La Soluzione: Gli strumenti del Sysadmin (dig e nslookup)

Per diagnosticare dove si interrompe la catena DNS, dobbiamo bypassare la cache del sistema operativo e interrogare direttamente i name server.

1. Ispezionare la risoluzione con `dig` o `nslookup`

Su Linux (o WSL su Windows), utilizza dig per tracciare il percorso della richiesta. Specifica il server DNS aziendale per capire se sta rispondendo ai record interni (es. il gestionale su intranet.local):

# Interroga specificamente il Domain Controller aziendale (10.0.20.5)
dig @10.0.20.5 intranet.local

Se il server restituisce un errore SERVFAIL, il problema risiede nei forwarder del server DNS. Se restituisce NXDOMAIN, il record semplicemente non esiste nella zona DNS.

2. Il conflitto del DNS over HTTPS (DoH) nei Browser

Un problema sempre più comune nelle reti aziendali è causato dal DNS over HTTPS (DoH). I browser moderni (Chrome, Edge, Firefox) bypassano le impostazioni DNS della scheda di rete di Windows e criptano le richieste inviandole direttamente a Cloudflare o Google. Il risultato? L'utente naviga su internet ma non riesce ad accedere alle risorse aziendali interne, perché il DNS pubblico non conosce la vostra zona privata.

Per risolvere, disabilita il "DNS Sicuro" all'interno delle impostazioni di privacy del browser o forza il traffico tramite policy GPO (Group Policy Object).

3. Verificare i file Host e Resolv.conf

Su macchine Linux, assicurati che il processo di risoluzione stia puntando al server corretto. Ispeziona il file di configurazione:

cat /etc/resolv.conf

Se è gestito da systemd-resolved, controlla lo stato globale della risoluzione eseguendo:

resolvectl status

The Problem: Connectivity Exists, Resolution Fails

Image generated with Gemini AI

It is a recurring nightmare: the server successfully replies to ping 8.8.8.8, but attempting to reach an internal or external domain returns ERR_NAME_NOT_RESOLVED in the browser. The standard ipconfig /flushdns command had zero effect. In these advanced scenarios, simply restarting the network adapter is useless; you need to surgically inspect the resolution chain.

The Solution: Sysadmin Tools (dig and nslookup)

To diagnose exactly where the DNS chain breaks, we must bypass the operating system's cache and query the name servers directly.

1. Inspecting Resolution with `dig` or `nslookup`

On Linux (or WSL on Windows), use dig to trace the request path. Specify your corporate DNS server to see if it responds correctly to internal records (e.g., your intranet at intranet.local):

# Specifically query the corporate Domain Controller (10.0.20.5)
dig @10.0.20.5 intranet.local

If the server returns a SERVFAIL error, the issue lies within the DNS server's forwarders. If it returns NXDOMAIN, the record simply does not exist in the DNS zone.

2. The DNS over HTTPS (DoH) Browser Conflict

An increasingly common issue in corporate networks is caused by DNS over HTTPS (DoH). Modern browsers (Chrome, Edge, Firefox) bypass the Windows network adapter's DNS settings and encrypt requests, sending them directly to Cloudflare or Google. The result? The user can browse the public internet but cannot access internal corporate resources because the public DNS knows nothing about your private zone.

To fix this, disable "Secure DNS" within the browser's privacy settings, or enforce the block company-wide via Group Policy Objects (GPO).

3. Verifying Hosts and Resolv.conf

On Linux machines, ensure the resolution process is actually pointing to the correct server. Inspect the configuration file:

cat /etc/resolv.conf

If the network is managed by systemd-resolved, check the global resolution status by executing:

resolvectl status

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.

 It’s a classic. A friend comes over, asks for the Wi-Fi password, and you stare at them with the blank expression of someone who just got asked a quantum physics question. Sure, you could get up, walk over to the router, and try to read that 24-character string of tiny letters printed on a faded sticker under a layer of dust... but it's 2026, we have better ways. And what if you changed the default password to "SuperSecret123" and forgot it? Don't panic. There's no need to hard reset the router and reconfigure the smart devices in half your house.