¿Hay alguna manera de agregar 0.0.0.0/0 al tipo ipset hash:net,port? Parece que solo admite longitudes de prefijo de 1 a 32, pero ¿qué sucede si quiero que una entrada en mi hash ipset admita todo el tráfico IP en un puerto determinado? Por ejemplo
ipset create testset hash:net,port
ipset add testset 0.0.0.0,22
iptables -I INPUT 1 -m set --match-set testset src, src -j ACCEPT
iptables -I INPUT 2 -j LOG --log-prefix "** FIREWALL **"
no hará nada. El tráfico SSH llegará al firewall y generará un registro. 0.0.0.0/0 no se acepta como notación CIDR válida, aunque parece que lo agregaron a hash:net,iface en la revisión 2. Soy consciente de que podría almacenar el puerto en un mapa de bits:puerto y aplicarlo al suyo propio. regla de iptables. Sin embargo, específicamente me gustaría almacenar puertos en un hash, ya que algunos puertos pueden preocuparse por la dirección IP src y otros no, y no quiero mantener un conjunto separado para 0.0.0.0/0.
Respuesta1
La sintaxis correcta sería usar 0.0.0.0/0 ya que 0.0.0.0 por defecto es 0.0.0.0/32. Lamentablemente, como descubrió, esto no es compatible:
# ipset add testset 0.0.0.0/0,22
ipset v7.3: The value of the CIDR parameter of the IP address is invalid
Lo que puedes hacer en su lugar es usar el mismo tipo de truco que se usa en OpenVPN al anular rutas: dividir 0.0.0.0/0 por la mitad: 0.0.0.0/1 y 128.0.0.0/1:
ipset add testset 0.0.0.0/1,22
ipset add testset 128.0.0.0/1,22
Nota:
Generalmente, para un servidor que ejecuta unlocalservidor ssh, eliptablesLos parámetros probablemente deberían ser estos:
iptables -I INPUT 1 -m set --match-set testset src,dst -j ACCEPT
Ya que estamos en elAPORTEcadena, significadorecepción, src,dstsignifica verificar la IP remota (origen) y el puerto local (destino), mientras que src,srcsignificaría verificar la IP remota (origen) y el puerto remoto (origen). El único uso para esto sería permitir el tráfico de respuesta desde servidores ssh remotos, pero esto normalmente ya se manejaría en -m conntrack --ctstate ESTABLISHEDotro lugar.