firewalld vs iptables - quando usare quale [chiuso]


29

TL; DR Su nuove installazioni di server CentOS dovrei usare firewalld o semplicemente disabilitarlo e tornare a utilizzare /etc/sysconfig/iptables?


firewalld e iptables hanno scopi simili. Entrambi eseguono il filtraggio dei pacchetti, ma se lo capisco correttamente firewalld non annulla l'intero set di regole ogni volta che viene apportata una modifica.

So molto su iptables ma molto poco su firewalld.

Su Fedora e RHEL / CentOS - è stata eseguita la tradizionale configurazione di iptables /etc/sysconfig/iptables. Con firewalld, la sua configurazione vive /etc/firewalld/ed è un insieme di file XML. Fedora sembra muoversi verso firewalld in sostituzione di questa configurazione legacy. Capisco che firewalld usa iptables sotto il cofano, ma ha anche la sua interfaccia della riga di comando e il formato del file di configurazione come sopra - che è ciò a cui mi riferisco in termini di utilizzo dell'uno contro l'altro.

Esiste una configurazione / scenario particolare per cui ognuno di questi è più adatto? Nel caso di NetworkMangaer vs network, sembra che NetworkManager possa essere stato inteso come un sostituto per gli script di rete, a causa della mancanza del supporto del bridge di rete e di poche altre cose, molte persone non lo usano solo nelle configurazioni del server su tutti. Quindi sembra esserci un concetto generale di "usa NetworkManager se sei su un Linux desktop/guie rete se stai eseguendo un server". Questo è proprio quello che raccolgo leggendo vari post, ma almeno fornisce una guida su ciò che è un uso praticabile per quelle cose, almeno così come si trovano nel loro stato attuale.

Ma ho fatto la stessa cosa con firewalld e semplicemente disattivandolo e usando invece iptables. (Sto quasi sempre installando Linux su un server, non per uso desktop). Firewalld è un sostituto efficace per iptables e dovrei usarlo su tutti i nuovi sistemi?


10
Firewalld utilizza iptables sotto.
user9517 supporta GoFundMonica il

Certo, e questo ha senso. Ma ovviamente c'è una grande differenza tra il modo in cui memorizzi la tua configurazione e quale strumento usi: iptables vs firewall-cmd, / etc / sysconfig / iptables vs /etc/firewalld/.../*.xml Revisionerò la domanda un po 'per renderlo più chiaro.
bgp,

Non è necessario "svuotare l'intero set di regole ogni volta che si crea una possibilità" iptables. È solo uno strumento di front-end, se sta svuotando i tavoli perché lo hai detto a.
gparent,

Per chiarire, mi riferisco al "riavvio del servizio iptables" che causa la rimozione e l'aggiunta di nuove regole. (Anche se ciò non influisce ancora sullo stato della connessione, il che è positivo.) Ovviamente puoi semplicemente eseguire il comando iptables dalla riga di comando per modificare le singole regole - ma generalmente cerco di mantenere tutto in / etc / sysconfig / iptables e utilizzare il comando "service" per attenersi alla convenzione suggerita dagli strumenti forniti dalla distribuzione.
BG

Risposte:


12

Poiché firewalldsi basa sulla configurazione XML, alcuni potrebbero pensare che sia più semplice configurare il firewall in modo programmatico. Ciò può essere ottenuto iptablesaltrettanto bene, ma con un modo diverso, che non è XML. Se hai già familiarità con il modo in cui iptablesfunziona, perché dovresti migrare tutta la configurazione firewalld?

Se consideri il tuo iptablesset di regole firewall più grande , con quale frequenza ritieni di trarre vantaggio dall'aspetto dinamico di firewalld? Nella maggior parte dei casi le prestazioni di iptablesnon sono mai il problema. Nella maggior parte dei casi in cui le prestazioni di iptablesun problema possono essere risolte utilizzando ipsetset IP di origine / destinazione basati.

È un dibattito diverso se utilizzare NetworkManager o meno.


3
Le prestazioni di iptablesnon sono rilevanti in questo caso perché la lentezza si verificherà indipendentemente dal fatto che le regole vengano inserite tramite firewalldo direttamente con lo iptablesstrumento.
sabato
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.