Firewall Firewalld in OpenSUSE

 

Il firewall è cambiato in OpenSUSE, vediamo come….

 

 

 

Ovviamente questa è solo una infarinatura generale per meglio capire il funzionamento del nuovo firewall e non una trattazione o una guida completa per ovvi motivi.

 

Richiede una certa conoscenza di base sul uso di un firewall.

 

Perchè

 

Il vecchio firewall era oramai non più sviluppato ma solo mantenuto, dato che nella sezione produzione industriale si usano zone firewall ovvero veri server che servono solo per quello scopo, mentre quello della RH era migliorato copiando molte soluzioni del firewall OpenSUSE chiamato SuSEFirewall2.

 

SuSEfirewall2, fondamentalmente era uno script che genera regole iptables dalla configurazione memorizzata nel file /etc/sysconfig/SuSEfirewall2 . SuSEfirewall2 proteggeva dagli attacchi di rete rifiutando o eliminando alcuni pacchetti indesiderati che potevano raggiungere l’interfaccia di rete questo con solo 3 tipi di gruppi di connessione:

  • EXT - External Zone (ie untrusted, Internet)

  • INT  ​​​​ - Internal Zone (fully trusted, no filtering, LAN)

  • DMZ - Demilitarized Zone

     

Non era male: Leggerissimo, consentiva Servizi Condivisi, Masquerading (mascheramento) con inoltro agli host mascherati, Reindirizzamento trasparente, ​​ Logging completo, HTB - Ottimizzazione della velocità di caricamento massima, ​​ Regole personalizzate, PERÒ spesso necessità del riavvio di tutta la macchina, SIPv4 e/o IPv6 e solo iniziale, Susefirewall2 che non supporta tutte le funzionalità su IPv6 ed ​​ Elenco di parole chiave non funzionanti: FW_TRUSTED_NETS FW_SERVICES_ACCEPT_EXT , ecc..

 

 

Pertanto sulla versione 15 si è deciso di migrare al Firewalld che comporta diversi miglioramenti, integrazione SystemD, multi gruppi d'accesso alle connessioni invece dei soli 3 tipologie di gruppi di connessione, uso delle nuove chiamate Kernel e IPtable, pieno supporto IPv4 & IPv6, ecc.

 

Altre Caratteristiche:

  • Può gestire IPv4, IPv6 e bridge "sotto lo stesso tetto"

  • Modifica dinamica delle regole tramite chiamate DBUS con autenticazione del policykit senza dover ricaricare l'intero firewall

  • Completamente integrato con NetworkManager (ma anche Wiked)

  • Utilità di cifratura grafica: firewall-config (da rivedere con Yast)

  • Strumento di configurazione della riga di comando: firewall-cmd

  • Già testata come soluzione per SUSE e collaborazione RH

  • ecc.. API D-Bus completa IPv4, IPv6, bridge e supporto ipset Supporto NAT IPv4 e IPv6 Zone firewall Zone predefinite di zone, servizi e icmptypes Servizio semplice, porta, protocollo, porta sorgente, masquerading, port forwarding, filtro icmp, regola ricca, interfaccia e indirizzo sorgente handlig in zone Semplice definizione del servizio con porte, protocolli, porte sorgente, moduli (netfilter helper) e gestione degli indirizzi di destinazione Rich Language per regole più flessibili e complesse nelle zone Cronometraggio delle regole del firewall nelle zone Registro semplice dei pacchetti negati Interfaccia diretta Blocco: Whitelist di applicazioni che possono modificare il firewall Caricamento automatico dei moduli del kernel Linux Integrazione con Puppet Clint di riga di comando per la configurazione online e offline Strumento di configurazione grafico utilizzando l'applet gtk3 utilizzando Qt4, inoltre integrazioni con

    •  ​​ ​​ ​​​​ NetworkManager

    •  ​​ ​​ ​​​​ libvirt

    •  ​​ ​​ ​​​​ Docker (prodotto che punta molto SUSE)

    •  ​​ ​​ ​​​​ fail2ban

     

Ma una cosa è particolarmente pesata, un possibile buco della sicurezza anche se al livello paranoide, e quindi si provvede alla migrazione prima che sia completa l’interfaccia Yast.

 

Pecche Firewalld

 

In effetti in Yast ora bisogna utilizzare l’interfaccia grafica propria di Firewalld invece di una costruita per Yast (peggio il Web-Yast) e quindi anche funzionante alla “riga comando” e con una impostazione classica del modo d’utilizzo e senza la necessità, al primo avvio di scaricare altre componenti.

Sfortunatamente, firewalld e firewall-cmd sono stati creati per un sistema operativo Linux aziendale (RHEL) e quindi sembrano progettati per essere utilizzati da un amministratore di sistema piuttosto che da un utente.

Un altro guaio, per la portabilità, è che è stato fatto in Python e poi portato solo in parte in C++.

I servizi sono definiti come file XML contenenti mappature di porte e protocolli e, facoltativamente, informazioni extra come la specificazione di sotto-reti e l'elenco dei moduli helper del kernel richiesti. La sintassi è simile a quella dei file di servizio di systemd, ma crea molta confusione nella lettura “ad occhio” anche da parte di un esperto.

Limitazioni: Firewalld al momento non supporta le regole in uscita alla stessa capacità delle regole in entrata. Le limitazioni includono elementi quali ipset, nomi di servizio e blocco in uscita predefinito secondo le regole predefinite richieste da standard come NIST 800-171 e 800-53. Tutti i blocchi predefiniti devono essere eseguiti al livello "raw" IPTables tramite il flag --direct e, con l'ordine delle operazioni che FirewallD utilizza per dare la priorità alle regole, alle regole avanzate, alle regole dirette, potrebbe essere più semplice inserire tutte le regole per l'uscita tramite --direct o usa iptables (netfilter-persist).

 

Altro problema le migrazioni, ma è stato preparato uno script che vedremo in fondo.

 

Come

Vediamo un attimo come è organizzato il tutto

 

-Zone o gruppi

 

Un utente normale distingue le connessioni all’interno del PC, quello della sua rete e quella di internet, del resto il firewall in Windows è congegnato in questo modo.

Qui si possono fare gruppi di Zone per ogni gusto

 

Nell’esempio “la connessione via cavo1” possiede come Zona predefinita “public”, spostandoci ancora sulla destra vediamo quali Servizi possono avere accesso e ad esempio Apache2 non può avere accesso su questa Zona “Public” che è della “Connessione via cavo1”.

Quello che vediamo sulla estrema destra (esempio Apache2) sono Regole predefinite (Nome Regole) in un Nome (esempio Apache2) in modo da semplificare il lavoro sia del programmatore di quel programma sia l’amministratore della macchina.

​​ 

​​ 

Il resto dei Tab sono poi regole generali che possiamo dare (in esempio Public) alla Zona.

Non mi soffermo su cosa fanno in quanto un semplice amministratore di sistema già capisce cosa fare e cosa sono.

Ritorniamo alle Regole predefinite…

 

 

 

Cliccando sul Tab “Servizi” possiamo vedere come è questa Regola predefinita, nell’esempio Apache2, abbiamo liberato per lui la Porta di Comunicazione 80 ma solo in Protocollo TCP (e non UDP).

 

Nota: È possibile cambiare i servizi solo nella Vista Configurazione Permanente. La configurazione Runtime è fissa.  ​​​​ 

 

Le altre voci per i “Servizi” come Protocolli, Porta sorgente, ecc.. sono scarsamente usate.

 

Poi abbiamo IPSet che serve per creare liste bianche e nere ovvero ulteriori eccezioni.

 

 

Blocca:

gnome-screensaver-command -l && xset dpms force off

 

Sblocchi:

-Comando Firewall-cmd

 

Firewalld dispone di comandi in stile “SystemD” e quindi un firewall-cmd e quindi i ...

 

Tipici ​​ casi dell’uso del commando:

firewall-cmd --get-default-zone

Mostra la zona predefinita corrente per le nuove regole di interfaccia.

firewall-cmd --set-default-zone=<zone>

Cambia la zona predefinita.

firewall-cmd --info-zone=<zone>

Fai vedere il settaggio della Zona

 

firewall-cmd --zone=<zone> --change-interface=<interface> [--permanent]

 

Sposta un'interfaccia da una zona all'altra. La maggior parte delle zone (e in particolare una zona che viene fornita come predefinita, come "pubblica") sono preconfigurate per negare il traffico in entrata per impostazione predefinita (il traffico in uscita è consentito per impostazione predefinita). Se è necessario autorizzare un determinato traffico di rete in entrata (ad esempio, se si sta eseguendo un server web sulla propria casella), è necessario aggiungere una regola in modo esplicito. In genere, ciò avviene consentendo "servizi". Il set di servizi predefinito per la zona "pubblica" consente solo il traffico client SSH e DHCPv6 in entrata (le basi).

 

++---

 

firewall-cmd --get-services

Mostra un elenco di regole predefinite per i servizi di rete comuni. L'applicazione di un servizio a una zona è spesso il modo più semplice per consentire l'accesso a un'applicazione server in esecuzione sulla macchina (ad es. Apache o vsftpd).

 

firewall-cmd --info-service=<service>

le impostazioni di un servizio predefinito.

++--

Aggiungi un servizio a una zona per consentire l'accesso.

firewall-cmd --zone=<zone> --add-service=<service> [--permanent]

 

È possibile aggiungere più servizi nello stesso comando. Ad esempio, se si desidera consentire HTTP e HTTPS al proprio server, è possibile impartire il comando:

firewall-cmd --zone = public --add-service = http --add-service = https –permanent


L'opposto di --add-service è –remove-service :

firewall-cmd --zone=<zone> --remove-service=<service> [--permanent]

 

Rimuove un servizio da una zona. Potresti voler consentire qualcosa che non è definito in un servizio preesistente. È possibile creare i propri servizi se è necessaria più porte e / o protocolli, ma il metodo più semplice per le regole semplici è quello di utilizzare –add-port:

firewall-cmd --zone=<zone> --add-port=<port>/<proto> [--permanent]

Per esempio, se è necessario consentire la porta TCP 8080 al server (permanentemente):

firewall-cmd --zone=public --add-port=8080/tcp –permanent

Come con i servizi, --remove-port è l'opposto di –add-port :

firewall-cmd --zone=<zone> --remove-port=<port>/<proto> [--permanent]

 

Migrazione

 

Si tratta di un semplice script bash che mira a fornire un percorso di migrazione di base da SuSEfirewall2 a FirewallD. Tuttavia, poiché SuSEfirewall2 offre una grande flessibilità, lo script potrebbe non riuscire o rifiutare di migrare determinate regole. Questo è utile, poiché la migrazione di ogni possibile regola di iptables renderebbe lo script piuttosto complesso e porterebbe anche a una configurazione FirewallD complicata e non più mantenuta. Questo script cercherà di migrare almeno le zone e i servizi ben noti, ma potrebbe non riuscire a fare qualcosa di più sofisticato. Se ritieni che manchi una funzionalità critica, apri una segnalazione di bug, ma tieni presente che questo script non è un traduttore accurato tra le configurazioni di SuSEfirewall2 e firewalld. Poiché l'unico scopo di questo script è quello di fornire un punto di partenza per la migrazione di SuSEfirewall2 a FirewallD, è probabile che il risultato non sia al 100% indentico a quello che si aveva con SuSEfirewall2 e qualche intervento dell'utente potrebbe essere necessario per ottenere i risultati desiderati.

 

https://github.com/openSUSE/susefirewall2-to-firewalld

 

 

Conclusioni

 

Un rapporto di uso e benefici che portano al nuovo Firewall e l’integrazione di SUSE con OpenSUSE ovvero del mondo prevalente del Server con quello del prevalente del “utente singolo”, costringono queste scelte.

 

Spero che una “clientela” aumentata grazie al SUSE forzi lo sviluppo verso una sua semplificazione e cura dei vari difetti, di contro non ci troviamo su un prodotto tanto complicato.

 

Chi vivrà vedrà!

 

Ciaoooooooooooooooooooooooooooooooooooo

Precedente BlueProximity in openSUSE Successivo XscreenSaver su OpenSUSE