NAT y filtrado de IP de origen en PF, usando OpenBSD> = 4.7

8

Acabo de leer un libro sobre PF (The Book Of PF, No Starch), pero hay una pregunta que no responde.

Si tengo una máquina de puerta de enlace que usa dos interfaces, $ int_if y $ ext_if, y hago NAT los paquetes que vienen de $ int_if: net (que es, digamos, 10.0.0.0/24) a $ ext_if usando match, cuando se aplica el NAT ? ¿Antes o después de las reglas de filtrado?

Ejemplo:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
pass out on $ext_if from 10.0.0.0/24
block drop out on $ext_if from 10.0.0.23

¿Eso funciona? ¿O obtiene la IP de origen de un paquete que viene de 10.0.0.23 NATed a la dirección de $ ext_if antes de evaluar si se evalúa si es de 10.0.0.23?

Creo que este diagrama no es útil para responder a esta pregunta, pero es interesante, sin embargo: [ http://www.benzedrine.cx/pf_flow.png ]

Si lee las preguntas frecuentes de PF NAT [ http://www.openbsd.org/faq/pf/nat.html ], especialmente la sección "Configuración de NAT", se encontrará con estas oraciones:

Cuando se selecciona un paquete mediante una regla de coincidencia, los parámetros (por ejemplo, nat-to) de esa regla se recuerdan y se aplican al paquete cuando se alcanza una regla de aprobación que coincide con el paquete. Esto permite que toda una clase de paquetes sea manejada por una sola regla de coincidencia y luego se pueden tomar decisiones específicas sobre si se debe permitir el tráfico con reglas de bloqueo y aprobación.

Creo que suena como si no fuera lo que dije en el párrafo anterior, por lo que la IP de origen se "recuerda" hasta que haya una decisión sobre la acción que se realizará con el paquete. Si se toma la decisión, se aplica el NATting.

¿Qué piensas?

PD: Esta es una pregunta bastante teórica. Si eres un poco pragmático, lo harás de esta manera:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop from 10.0.0.23
# or, explicitly,
# block drop in on $int_if from 10.0.0.23

Entonces, la blockregla ya se aplica cuando el paquete viene en $ int_if.

EDITAR: Otra posibilidad es, por supuesto, decidir antes de NAT:

pass from 10.0.0.0/24
block drop from 10.0.0.23
match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)

Si llega un paquete de .23, primero coincide con la primera regla, luego coincide con la segunda regla y la tercera "regla". Pero como la segunda regla es la última que decide sobre pasar / bloquear, el paquete se bloquea. ¿Derecha?

— dermesser
fuente

1

Sí, es bastante teórico lo que preguntaste, pero es una pregunta muy interesante.

La matchregla se aplicará cuando actúe sobre la última regla coincidente. matchlas reglas son "rígidas", como mencionaste. El objetivo principal de ellos es poder establecer cosas como una regla NAT una vez, y no tener que poner nat-to al final de un montón de reglas que tiene sobre el tráfico saliente.

En su ejemplo, el paquete se descartará. Tendría que mirar el código o pedirle a Henning Brauer que se asegure de omitir la verificación NAT por completo en el caso de caída, pero no se eliminaría NAT.

Creo que su regla está cubierta por el Libro de PF (¿tiene la segunda edición?), Pero no creo que sean explícitas al respecto con la regla de coincidencia.

— kurtm
fuente

0

Corríjame si estaba equivocado, ¿desea pasar todos los paquetes salientes del 10.0.0.0/24 pero desea bloquear el 10.0.0.23? Si es así, cambie su regla a:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop out quick on $ext_if from 10.0.0.23
pass out on $ext_if from 10.0.0.0/24

Simplemente use quickpara evitar que el firewall continúe filtrando (similar a breaken algunos lenguajes de programación).

http://www.openbsd.org/faq/pf/filter.html#quick

La palabra clave rápida

Como se indicó anteriormente, cada paquete se evalúa contra el conjunto de reglas de filtro de arriba a abajo. De manera predeterminada, el paquete está marcado para el paso, que puede cambiarse mediante cualquier regla, y podría cambiarse varias veces antes de que finalicen las reglas del filtro. La última regla coincidente "gana". Hay una excepción a esto: la opción rápida en una regla de filtrado tiene el efecto de cancelar cualquier procesamiento adicional de la regla y hace que se tome la acción especificada. Veamos un par de ejemplos:

Incorrecto:
block in on fxp0 proto tcp to port ssh
pass  in all 
En este caso, la línea de bloqueo puede evaluarse, pero nunca tendrá ningún efecto, ya que luego es seguida por una línea que pasará todo.

Mejor:
block in quick on fxp0 proto tcp to port ssh
pass  in all 
Estas reglas se evalúan de manera un poco diferente. Si la línea de bloqueo coincide, debido a la opción rápida, se bloqueará el paquete y se ignorará el resto del conjunto de reglas.

Soy consciente de la quickpalabra clave, pero no me gusta, siempre trato de usar el orden de evaluación de pf;) Por cierto, encontré la respuesta en una página de preguntas frecuentes de OpenBSD: "NAT se especifica como un parámetro opcional nat-to para una regla de aprobación saliente. A menudo, en lugar de establecerse directamente en la regla de aprobación, se utiliza una regla de coincidencia. Cuando un paquete es seleccionado por una regla de coincidencia, los parámetros (por ejemplo, nat-to) de esa regla se recuerdan y se aplican a paquete cuando se alcanza una regla de aprobación que coincide con el paquete ". Entonces, mi conjunto de reglas no causaría ningún problema y bloquearía correctamente .23

— dermesser

(la regla de coincidencia en la línea 2 deja pasar los paquetes después de pasar por todas las reglas y luego se aplica NAT)

— dermesser