firewalld vs iptables - cuando usar cual [cerrado]


29

TL; DR En las nuevas instalaciones del servidor CentOS, ¿debería usar Firewalld o simplemente deshabilitarlo y volver a usarlo /etc/sysconfig/iptables?


firewalld e iptables tienen propósitos similares. Ambos filtran paquetes, pero si lo entiendo correctamente, firewalld no elimina toda la regla establecida cada vez que se realiza un cambio.

Sé mucho sobre iptables pero muy poco sobre firewalld.

En Fedora y RHEL / CentOS, la configuración tradicional de iptables se realizó en /etc/sysconfig/iptables. Con firewalld, su configuración vive /etc/firewalld/y es un conjunto de archivos XML. Fedora parece estar avanzando hacia Firewalld como un reemplazo para esta configuración heredada. Entiendo que firewalld usa iptables debajo del capó, pero también tiene su propia interfaz de línea de comandos y formato de archivo de configuración como se mencionó anteriormente, que es a lo que me refiero en términos de usar uno frente al otro.

¿Existe una configuración / escenario particular para el que cada uno de estos es el más adecuado? En el caso de NetworkMangaer vs network, parece que aunque NetworkManager puede haber sido un reemplazo para los scripts de red, debido a su falta de soporte de puente de red y algunas otras cosas, muchas personas simplemente no lo están utilizando en las configuraciones del servidor en todos. Por lo tanto, parece haber un concepto general de "usar NetworkManager si está en un Linux desktop/guiy red si está ejecutando un servidor". Eso es justo lo que aprendí al leer varias publicaciones, pero al menos da una guía sobre lo que es un uso viable para esas cosas, al menos en su estado actual.

Pero he estado haciendo lo mismo con firewalld y simplemente lo apagué y usé iptables en su lugar. (Casi siempre estoy instalando Linux en un servidor, no para uso de escritorio). ¿Firewalld es un reemplazo efectivo para iptables y debería usarlo en todos los sistemas nuevos?


10
Firewalld usa iptables debajo.
user9517 es compatible con GoFundMonica

Claro, y eso tiene sentido. Pero obviamente hay una gran diferencia entre cómo almacena su configuración y qué herramienta utiliza: iptables vs firewall-cmd, / etc / sysconfig / iptables vs /etc/firewalld/.../*.xml Revisaré la pregunta un poco para aclarar eso.
bgp

No hay necesidad de "vaciar todo el conjunto de reglas cada vez que se hace una oportunidad" iptables. Es solo una herramienta de front-end, si está limpiando las tablas es porque se lo dijiste.
gparent

Para aclarar, me refiero al "reinicio de iptables del servicio" que hace que las reglas se eliminen y se vuelvan a agregar. (Aunque eso todavía no afecta el estado de la conexión, lo cual es bueno). Por supuesto, puede ejecutar el comando iptables desde la línea de comandos para modificar las reglas individuales, pero generalmente trato de mantener todo en / etc / sysconfig / iptables y utilice el comando "servicio" para cumplir con la convención sugerida por las herramientas proporcionadas por la distribución.
BGP

Respuestas:


12

Como firewalldse basa en la configuración XML, algunos podrían pensar que es más fácil configurar el firewall de manera programática. Esto se puede lograr de la iptablesmisma manera, pero con una forma diferente, que no es XML. Si ya está familiarizado con la forma en que iptablesfunciona, ¿por qué migraría toda su configuración firewalld?

Si considera su iptablesconjunto de reglas de firewall más grande , ¿con qué frecuencia cree que se beneficiaría del aspecto dinámico de firewalld? En la mayoría de los casos, el rendimiento iptablesnunca es el problema. En la mayoría de los casos en que el rendimiento de iptablesun problema se puede solucionar mediante el uso de ipsetconjuntos de IP de origen / destino basados.

Es un debate diferente si debe usar NetworkManager o no.


3
El rendimiento de iptableses irrelevante en este caso porque la lentitud ocurrirá independientemente de si las reglas se insertan a través firewalldo directamente con la iptablesherramienta.
gparent
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.