Nethesis
NethSecurity: port forwarding e regole firewall non sono la stessa cosa
Pubblicare un servizio interno e autorizzare il traffico tra reti sono operazioni diverse. Capire la distinzione aiuta a evitare aperture eccessive e configurazioni difficili da controllare.
Dall’esterno la rete privata è normalmente chiusa
Un server collocato nella rete aziendale non dovrebbe essere raggiungibile da Internet soltanto perché ascolta su una determinata porta. La documentazione NethSecurity spiega che il firewall impedisce normalmente alle richieste provenienti dalle reti pubbliche di accedere a quelle private. Quando un’applicazione deve essere disponibile dall’esterno, occorre quindi una decisione esplicita, collegata a una necessità reale. Prima della configurazione vanno identificati servizio, responsabile, destinatari, durata dell’esposizione e conseguenze di un abuso. “Aprire una porta” è un’espressione comoda, ma nasconde operazioni tecniche e rischi differenti.
Che cosa fa realmente un port forwarding
Il port forwarding, chiamato anche port redirect o DNAT, riceve il traffico destinato a una combinazione di indirizzo pubblico, protocollo e porta e lo inoltra verso un host interno. In NethSecurity è possibile indicare destinazione, eventuale porta diversa, indirizzo WAN specifico e sorgenti autorizzate. La funzione serve quindi a pubblicare un servizio che si trova dietro il firewall. Non rende sicura l’applicazione, non corregge password deboli e non installa aggiornamenti. L’opzione che inoltra tutto il traffico richiede particolare cautela: la stessa documentazione avverte che può esporre comunicazioni non previste o dannose.
Le regole firewall rispondono a un’altra domanda
Le regole stabiliscono se un traffico debba essere accettato, rifiutato, scartato o registrato in base a zone, sorgenti, destinazioni e servizi. NethSecurity distingue regole Forward, per i pacchetti che attraversano il firewall tra reti diverse, Input, per quelli diretti al firewall stesso, e Output, per quelli generati dal firewall. Anche l’ordine conta: viene applicata la prima regola corrispondente. Una regola tra LAN e una VLAN, per esempio, disciplina la comunicazione interna; non equivale alla pubblicazione di un server su Internet. Confondere i due concetti può produrre aperture inutili o un servizio irraggiungibile.
Destinazione interna e firewall non sono lo stesso oggetto
Se il servizio gira su un server della LAN, il traffico deve essere tradotto e inoltrato verso quell’indirizzo. Se invece è il firewall a offrire direttamente il servizio, il pacchetto ha come destinazione il firewall e la valutazione riguarda l’Input. Questa distinzione è importante anche nella diagnosi: una connessione può raggiungere l’indirizzo pubblico ma fermarsi perché l’applicazione non ascolta, il server usa un altro gateway oppure un dispositivo a monte esegue un’ulteriore traduzione. Prima di cambiare più regole insieme conviene verificare separatamente percorso, destinazione, servizio e risposta.
Un esempio con un portale riservato al fornitore
Immaginiamo un’azienda che debba rendere disponibile per un mese un portale HTTPS interno a un fornitore con indirizzo IP pubblico noto. Il responsabile documenta la richiesta, assegna al server un indirizzo stabile, limita il port forwarding al solo protocollo e alla sola porta necessari e restringe l’origine all’IP concordato. Il portale utilizza autenticazione adeguata, certificato valido e software aggiornato; i registri vengono controllati e la regola ha una data prevista di rimozione. La prova viene svolta da una connessione esterna autorizzata. È un esempio organizzativo ipotetico, non una configurazione universale né un’attività dichiarata di System & Software.
Per i servizi web esiste anche il reverse proxy
NethSecurity include una funzione reverse proxy per pubblicare applicazioni web HTTPS, gestendo associazione del nome e certificati. Non è però un sostituto automatico di ogni port forwarding. La documentazione segnala che, sullo stesso indirizzo WAN, una regola di inoltro della porta 443 ha precedenza e impedisce al traffico di raggiungere il web server del reverse proxy. Prima di scegliere bisogna quindi verificare architettura, nomi DNS, certificati e requisiti dell’applicazione. Servizi non web o protocolli particolari richiedono valutazioni diverse; sovrapporre meccanismi senza una mappa chiara rende la diagnosi più difficile.
I limiti da considerare prima dell’apertura
Una regola corretta sul firewall non risolve da sola doppio NAT, CGNAT dell’operatore, indirizzi pubblici dinamici o filtri presenti su un router a monte. Soprattutto, ridurre le sorgenti ammesse non sostituisce autenticazione, aggiornamenti, copie di sicurezza e controllo dei log. Per l’amministrazione remota, una VPN può essere più appropriata dell’esposizione diretta, ma va progettata e gestita correttamente. Ogni apertura dovrebbe avere proprietario, motivazione e revisione periodica. Quando non serve più, va rimossa dopo una verifica. La sicurezza nasce dal servizio completo e dal suo ciclo di vita, non dal semplice fatto che il firewall accetti una connessione.
Fonti e riferimenti
Fonti consultate il 28/10/2026.