¿Por qué no puedo usar la política de RECHAZO en mi cadena de salida de iptables?


11

Actualmente tengo mi cadena OUTPUT configurada en DROP. Me gustaría cambiarlo a RECHAZAR, de modo que tenga la idea de que es mi firewall que me impide llegar a algún lugar en lugar de un problema con cualquier servicio al que intento acceder (rechazo inmediato en lugar de tiempo de espera). Sin embargo, a iptables no parece importarle esto. Si edito manualmente mi archivo de reglas guardado e intento restaurarlo, obtengo iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy namey se niega a cargar las reglas. Si intento configurar esto manualmente ( iptables -P OUTPUT REJECT), obtengo iptables: Bad policy name. Run 'dmesg' for more information.pero no hay salida en dmesg.

He confirmado que la regla apropiada está compilada en el kernel y la he reiniciado para asegurarme de que está cargada:

# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y

(Se agregaron asteriscos para resaltar la regla aplicable)

Todo lo que puedo encontrar indica que REJECT es una política / objetivo válido (en general), pero no puedo encontrar nada que diga que no es válido para las cadenas INPUT, FORWARD o OUTPUT. Mi Google-fu no está ayudando. Estoy en Gentoo, si eso hace alguna diferencia. ¿Alguien aquí tiene alguna idea?


¿Puedes mostrar las iptablesreglas en cuestión?
bahamat

Respuestas:


15

REJECTes una extensión objetivo , mientras que una política de cadena debe ser un objetivo . La página del manual dice eso (aunque no está realmente claro), pero parte de lo que dice es completamente erróneo.

La política solo puede ser ACCEPTo DROPen cadenas incorporadas. Si desea el efecto de rechazar todos los paquetes que no coinciden con las reglas anteriores, solo asegúrese de que la última regla coincida con todo y agregue una regla con una REJECTextensión de destino. En otras palabras, después de agregar todas las reglas relevantes, hazlo iptables -t filter -A OUTPUT -j REJECT.

Consulte el hilo "cuáles son las posibles políticas de cadena" en la lista de netfilter para obtener más detalles.


Eso tiene sentido, y un RECHAZO genérico al final debería funcionar. Por curiosidad, ¿es la definición de extensión de destino en algún lugar bastante obvia y simplemente me la perdí, o es uno de los bits mal documentados?
ND Geek

1
Al leer toda la página de manual, está claro que REJECT es una extensión de destino, pero la página de manual es muy larga, por lo que "TL; DR" tiende a aplicarse. También implica que DROP, ACCEPT y QUEUE son objetivos de política válidos; del código actual, ¡COLA no lo es!
StarNamer

4

No pude encontrarlo documentado, pero una referencia aquí indica que las únicas políticas permitidas son ACCEPTor DROP. Esto se confirma mirando la fuente de libiptc(que es responsable de manipular las reglas) alrededor de la línea 2429, donde el código tiene

2429         if (strcmp(policy, LABEL_ACCEPT) == 0)
2430                 c->verdict = -NF_ACCEPT - 1;
2431         else if (strcmp(policy, LABEL_DROP) == 0)
2432                 c->verdict = -NF_DROP - 1;
2433         else {
2434                 errno = EINVAL;
2435                 return 0;
2436         }

El hilo original sugiere que lo mejor que puede hacer es agregar RECHAZAR al final de la cadena que debería ser iptables -A OUTPUT -j REJECT.

Tenga en cuenta que el código justo antes de esto es:

2423         if (!iptcc_is_builtin(c)) {
2424                 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425                 errno = ENOENT;
2426                 return 0;
2427         }
2428 

Por lo tanto, no puede establecer la política en una cadena definida por el usuario en absoluto.


Ese comando en el hilo es incorrecto; -pes para hacer coincidir un protocolo; quiso decir -Acomo dice mi respuesta.
Shawn J. Goff

Eso es muy interesante La curiosidad en mí se pregunta si hay una razón detrás de esto, o si así es como son las cosas, posiblemente por simplicidad (un código más simple significa menos puntos posibles para vulnerabilidades después de todo). Incluso si fuera un desarrollador moderado, podría tener la tentación de piratearlo localmente, pero como no lo soy, y dado que es un elemento de seguridad, no lo voy a tocar.
ND Geek

2

REJECTencendido OUTPUTno tiene sentido; a REJECTdevolverá un paquete ICMP que necesitaría atravesar una red.

Agregue una nueva -j LOGcomo su última regla (por lo tanto, antes de la DROPpolítica) para ver qué llega tan lejos en la OUTPUTcadena.


1
¿No podría el REJECTpaquete ICMP regresar en la interfaz lo? Estoy de acuerdo en que a LOGes útil para la resolución de problemas, pero lo que realmente esperaba es una forma de recordarme que "Oh, sí ... eso probablemente esté bloqueado por mi DROPvalor predeterminado de iptables" en lugar de solucionar problemas durante 5 minutos, le pide a un compañero de trabajo que El acceso al servidor XYZ se da cuenta de que probablemente sea local , que es mi enfoque más común, ya que mi día de trabajo típico rara vez golpea cosas que todavía no he abierto. Por supuesto, tal vez necesito tenerlo en cuenta mejor, pero un piso REJECTes más obvio.
ND Geek

No creo que quiera que la ethXinterfaz genere tráfico en la lointerfaz por muchas razones. Son muy independientes; puede hacer que las cadenas se apliquen fácilmente a una y no a la otra.
Aaron D. Marasco
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.